Re: Problems with 64-bit numbers

[acken@informatik.uni-kl.de]

>  Date: Mon, 13 May 96 08:07:25 EDT
>  From: Mike Griebling <grieblm@trt.allied.com>
>  
>  > I missed one important feature in the list: set constant constructors.
>  > The standard constructor "{...}" builds a value of type SET.  But how
>  > are constants of type SET8 or SET16 defined?
>  > ...
>  > Another way is to introduce implicit type conversion rules like the
>  > ones applied to integer values, 
>  > ...
>  
>  I think this can be made simpler by noting what type the constant is
>  being assigned to and then performing an implicit conversion of the
>  constant to that particular set type.
>  
>  As far as the actual implementation goes, at least for the PPC, ALL
>  operations will be 32-bits anyway so no conversion needs to be done.
>  The only place where conversions may occur is when saving/loading
>  shorter sets -- even then it is only a special form of the save/load
>  instruction.  BTW, the same goes for all the integer conversions.
>  
>  For example:
>  
>  CONST
>    Mask1 = {0..3};  (* nominally a SET/HUGESET type but is convertable *)
>    Mask2 = {8..9};
>  
>  VAR
>    set1 : SET;
>    set2 : SYSTEM.SET8;
>    set3 : SYSTEM.SET16;
>  
>  BEGIN
>    set1 := Mask1;  (* legal *)
>    set2 := Mask1;  (* also legal *)
>    set3 := Mask1;  (* legal as well *)
>    set1 := Mask2;  (* ok *)
>    set2 := Mask2;  (* oops, compile-time range error *)
>    set3 := Mask2;  (* ok *)
>    set1 := set2 + set3;  (* compile-time error -- no implicit var conversions *)
>    set1 := LONG(LONG(set2)) + LONG(set3);  (* ok *)
>  END Demo.

If there have to be implicit conversions, then I want them to behave
like the integer conversions.  This means that these additional rules
apply to set arithmetic as well as to set comparisons, regardless if
the operands are constants or variables.  IMO making a distinction
between variables and constants (if they have the same type) is a
broken design.

Seen this way, 
  set1 := Mask1 + Mask2
isn't handled handled in a different way than
  set1 := set2 + set3,
because both operations have the same signature (SET:=SET8+SET16).

>  > My statement that I don't like implicit type conversion still stands.
>  > On the other hand I'd like to have 8 and 16 byte sets for a simple
>  > interface to C libs, e.g. X11.  Does anyone agree with the type
>  > conversion scheme?
>  
>  Yes, set constants would be implicitly converted based on the assigned to
>  type but variables would be explicitly converted. (see example above)  As
>  stated, on a PPC, the explicit conversions disappear anyway so there is
>  no overhead implied.  From a language viewpoint I guess the explicit
>  conversions might buy you something (although I can't see what) -- maybe 
>  you could explain why you don't like implicit set conversions?

I dislike the implicit conversions because they add something to the
language that doesn't have SYSTEM written all over it.  And I don't
want to provide to much comfort to use non-standard features.  

-- mva