[M3devel] Integer literals

[hendrik at topoi.pooq.com]

On Sun, Jan 10, 2010 at 03:23:28PM -0500, 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).
> 
> 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.
> 
> 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.

And what would be the type of 2000000000 + 2000000000?  Overflow because 
2000000000 is an INTEGER?
Whereas 3000000000 + 3000000000 would end up being LONGINT?

The only solutions I see for this problem are:

(a) Explicitly tag every literal to identify it as INTEGER or LONGINT.

or

(b) Let operations on integers automatically produce values of 
sufficiently large ranges to be able to contain the results.

(b) seems to be incompatible with the use of the most efficient integer 
operations on a machinem=, which are of fixed bit-width.

(a) is what's proposed for the LONGINT extension.

It would be possible to combine (a) and (b), using (b) only for LONGINT, 
but you seem to be dead set against this.

-- hendrik

> 
> 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
> 
> 
> 
>