[M3devel] Integer literals

[Tony Hosking]

Yes, I agree.  I am now convinced that relaxing the current spec to allow assignability and mixed operand arithmetic is a swamp that we should steer well clear of.

On 11 Jan 2010, at 19:45, Rodney M. Bates wrote:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/33599c21/attachment-0002.html>