[M3devel] Integer literals

Rodney M. Bates rodney_bates at lcwb.coop
Tue Jan 12 01:45:27 CET 2010



Tony Hosking wrote:
> One thing I've really struggled with over the introduction of LONGINT is 
> the need for distinct literal forms.  This strikes me as odd, since 
> literals are really just ways of writing values, rather than stating 
> anything about how they should be represented.
> (Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, 
> but they really do have incompatible value representations).

I agree, the need for distinctly typed literals is much greater for the
floating types than the integer types, because they can't be viewed
as having overlapping value sets in any reasonable way.

> 
> It strikes me that with checked assignability for INTEGER/LONGINT we 
> could also potentially treat integer literals as essentially "untyped" 
> (neither INTEGER nor LONGINT). (I still strongly resist going the route 
> of having mixed type operands for arithmetic...)
> 
> Here's how things would work with subrange types.
> 
> A subrange written as currently
> 
> [lo .. hi]
> 
> would by default be assumed to have base type INTEGER.  The constants 
> lo/hi must both be in range for INTEGER.
> 
> A subrange with base type LONGINT would be written explicitly:
> 
> [lo .. hi] OF LONGINT
> 
> The constants lo/hi must both be in range for LONGINT.
> 
> We could also support the form:
> 
> [lo .. hi] OF INTEGER
> 
> just for consistency though the "OF INTEGER" qualification would be 
> unnecessarily verbose.
> 
> Here we are allowing the programmer to state explicitly what the base 
> type of the subrange should be.

This would eliminate _one_ reason for needing distinct integer literals.

> 
> Literals would be be range-checked when used as arithmetic operands or 
> in assignment, with compile-time checks that they are in range 
> ("compatible") with the types of the other operands or the destination 
> of the assignment.

The reason I proposed the distinct literals is because of feeling very
badly burned by Ada.  It has a type "universal integer", which is builtin,
and all integer literals have this type.  They have unbounded range and
a complete set of arithmetic operators, which can only be evaluated at
compile time.  The type "universal integer" can't be named in source
code.

The rules for when they are converted to a type having a runtime representation
are complicated, messy, highly surprising, and a huge complication of the
language.  Static type information can propagate a long way through
language constructs.  The programmer's dilemma in figuring out just what
is happening is much worse than arithmetic operators that accept mixed
sizes and do the computation in the larger size.

Maybe the semantics of this idea could be done better than in Ada, but I spent
a lot of time trying, and didn't come up with anything that wasn't both too
complicated and not worth the gain, IMO.

We should come up with a complete language proposal before going this way.


> 

> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 



More information about the M3devel mailing list