Re: Problems with 64-bit numbers

[acken@informatik.uni-kl.de]

>  Date: Mon, 13 May 96 14:29:59 EDT
>  From: Mike Griebling <grieblm@trt.allied.com>
>  
>  I'm not sure what you're saying?  It seems that constants ARE a special
>  case because they don't have a specific type -- unless you were saying
>  earlier that set constants would take on the value of the smallest set
>  type which would contain them?  

Not having a specific type is a specific type ;-).  No, I mean it's
easier to assign an existing set type to constants like {0..3},
{8..15}, etc.  Introducing the Modula-2 notion of a `conceptual' type
(Modula-2 assigns such a type Z to whole number constants, since they
can be mapped to INTEGER _and_ CARDINAL types) would be quite
complicated to add to the current front-end.  On the other hand, the
type assignment to integer constants (depending on the value) and
implicit integer type conversions (to larger types) do exist and are
fairly easy to copy for sets.

>  The problem I see with this definition is that set constants might then
>  have to implicitly import a SYSTEM definition.   

I can't follow you here.

>  If we're going to have set constants AND you don't want implicit conversions
>  then they have to be defined as being of the largest set type available
>  for a given compiler (i.e., SET or HUGESET).  The user then has to perform
>  explicit conversions to make them compatible with the SYSTEM-defined sets.

Actually, having two different kind of sets (SET and HUGESET) gives
the same problem.  Unless it's specified that you can only build SET
values with { ... }.

>  > 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.  
>  
>  Well, this seems like a strange statement after we are going all out to
>  introduce a new COMPLEX data type which is very comfortable to use.  I
>  would also consider the COMPLEX data type to be non-standard and thus 
>  should be defined in the SYSTEM.  Why make the silly distinction for
>  sets then?  They should be just as easy to use as COMPLEX numbers are.

You got me ;-).  I'd make the (very fine) distinction, that COMPLEX is
introduced for math applications, while SET8&co is introduced to
interface to existing libs (most of all, C).

>  Perhaps putting sets in the SYSTEM module is wrong as well since they
>  are portable just non-standard in the same way that our introduction
>  of the COMPLEX type is non-standard but could be portable.

My opinion:
  declare SET8, SET16, SET32, and SET64 in system
  declare HUGESET as predefined type
where SET is an alias for SET32, and HUGESET for SET64.  The latter
two types will be available for 64 bit implementations of the
compiler, and for those back-ends that support it (the C back-end
together with GCC will be able to provide 64 bit types, I think).

>  Mathematicians don't make any distinction on the size of a set.  They
>  would consider all sets to be compatible no matter what number of elements
>  they contain.  In this light, I would argue that ALL upward conversions 
>  should be implicit since:
>  
>    1) this is the way the real world mathematical sets work
>    2) there is no execution penalty in doing so
>    3) it makes life easier for the programmer using sets
>  
>  Converting to shorter sets will require an explicit conversion just like
>  integers do.

Yes.  This is exactly what I had in mind.  Just like integers...

>  
>  Thus:
>       SET8 > SET16 > SET > HUGESET (where > means "is contained in")
>  
>  As well:
>  
>       SHORT(SET16)   gives SET8
>       SHORT(SET)     gives SET16
>       SHORT(HUGESET) gives SET
>  
>  The explicit down-conversion gives the compiler an opportunity to insert
>  some overflow tests in case any set elements are truncated by the operation.
>  This is roughly equivalent to signalling an integer overflow when applying
>  a SHORT() to an integer which is too large to fit into the next smaller type.

A very useful specification.  The corresponding LONG conversions will
be available, too.

-- mva