🚀 go-pugleaf

In article <491@ethz.UUCP> aplusl@ethz.UUCP (Albert Meier) writes:
>The proposal adopted at the Nice meeting can be summarised as follows
> 
>                         To convert an Expression of type
> 
>                Integer Cardinal    Real    Longreal    Char     Enum
>      To a result
>      of type
> 
>      Integer      -    CONVERT    CONVERT   CONVERT     *         *
> 
>      Cardinal  CONVERT     -  CONVERT/TRUNC CONVERT  CONVERT/ORD
>CONVERT/ORD
> 
>      Real      CONVERT CONVERT/FLOAT -      CONVERT     *         *
> 
>      Longreal  CONVERT CONVERT    CONVERT     -         *         *
> 
>      Char         *    CONVERT/CHR  *         *         -         *
> 
>      Enum         *    CONVERT      *         *         *         -
>[Another suggestion:] 
>                         To convert an Expression of type
> 
>                Integer Cardinal    Real    Longreal    Char     Enum
>      To a result
>      of type
> 
>      Integer      -       INT      INT       INT       INT       INT
> 
>      Cardinal   CARD/ORD   -     CARD/TRUNC  CARD    CARD/ORD  CARD/ORD
>
>      Real       FLOAT    FLOAT      -        FLOAT      *         *
> 
>      Longreal   LFLOAT   LFLOAT   LFLOAT      -         *         *
> 
>      Char       CHR       CHR       *         *         -         *
> 
>      Enum       CONVERT  CONVERT    *         *         *         -

I have several objections to both of these porposals:

1) What about subrange types?  Simply changing one of the bounds could
make such types change from long to short (or short to long), or from
INTEGER to CARDINAL.  The following code may break: 

  TYPE    

    SubRange1 = [min1..max1];
    SubRange2 = [min2..max2];

  ...

  aValueOfSubRange1 := INT(aValueOfSubRange2);

This code is not portable because it hard-codes the fact that SubRange1
is an INTEGER subrange and that SubRange2 is a CARDINAL subrange.  If
the values of min1, max1, min2 and max2 are system-dependent values,
then the code will certainly be busted as it is ported from system to
system.  On the other hand, if the bounds constants are application
dependent, then the code can not be made generic to all applications.

Better would be the following:

  aValueOfSubRange1 := SubRange1(aValueOfSubRange2);

  -- or even --

  aValueOfSubRange1 := VALUE(aValueOfSubRange2);

Now the code is valid as long as a meaning-preserving conversion is
possible between the two types.  It the two types are the same, then
it is simply a null operation.  If the right-hand-side value is out
of range of the SubRange1, then a run-time exception occurs.

2) The proposals are too complicated with exceptions and different
keywords for a single operation: meaning-preserving conversion.  
Modula-2 is getting too many built-in types to even think about having
a different conversion operator for each possible combination.  Keep it
simple, stupid!  Quick, can you remember which conversions between the
basic types are legal and illegal in the proposals quoted above?


-- 
Alan Lovejoy; alan@pdn; 813-530-8241; Paradyne Corporation: Largo, Florida.
Disclaimer: Do not confuse my views with the official views of Paradyne
            Corporation (regardless of how confusing those views may be).
Motto: Never put off to run-time what you can do at compile-time!