[M3devel] LONGINT, my original proposal

[Rodney M. Bates]

Tony Hosking wrote: (excerpted)
>........................................
>> 2. FIRST(LONGINT) <= FIRST(INTEGER) and LAST(INTEGER) <= LAST(LONGINT).
> 
> Currently, direct comparison between LONGINT and INTEGER is not 
> permitted.  If it were then this would be true.
> 


I remember there was some vexing problem about what the result type
should be for FIRST and LAST, but not the details.  It seems to
me now that the only thing that makes any sense is to preserve the
existing rule that it is the base type of the argument type.
This is really necessary to preserve existing semantics of the
language and of existing code.

This original proposal seems to be silent on the matter, which I suppose
means I intended it as a NO CHANGE.  I guess, if
mixed relations are allowed, then I can't think of a problem
with this.  Even if mixed relations are disallowed, this range
constraint could be expressed with explicit conversions, I suppose.

.......................................................................

> 
>> 15. There is a new builtin type named LONGCARD.  It "behaves just
>>    like" (but is not equal to) [0..LAST(LONGINT)].
>>
>>      The current CARDINAL has an interesting history.  Originally, it
>>      was just a predefined name for the type [0..LAST(INTEGER)].  It
>>      was later changed to be "just like" the subrange, i.e., the two
>>      are not the same type, but have the same properties in every
>>      other respect.  The only reason for the change had to do with
>>      reading pickles, which are completely defined and implemented as
>>      library code.  The change did affect the type analysis of the
>>      language, nevertheless.
>>
>>      We should preserve this property for LONGCARD too.
> 
> Currently there is no implementation of LONGCARD.  I argue that we don't 
> need LONGCARD (since, as discussed below, NUMBER should stay typed as 
> CARDINAL), unless LONGCARD is needed for pickles...  Rodney?
> 

LONGCARD is needed for pickles (and for no other reason, that I can
think of).  The problem is that if a record or object has a field of
type [0..LAST(LONGCARD)], the actual value of LAST(LONGCARD) causes
the type to be different on different target machines, making a pickle
written on, say a 32-bit machine unreadable on a 64-bit machine.
LONGCARD can be treated as the same type regardless of word size,
allowing the automatic size changes pickles already does for INTEGER,
CARDINAL, and LONGINT to extend to this subrange too.

(Note: If you try to extend this size-changing by pickles to arbitrary
subranges that use FIRST/LAST/NUMBER in their bounds expressions, you
are jumping head first into a tar pit.  I've thought about it just enough
to conclude I wanted to step back.)

.......................................................................

>> 20. The statement that the upperbound of a FOR loop should not be
>>    LAST(INTEGER) also applies to LAST(LONGINT).
> 
> Agreed.
> 
>>      Note that the existing definition of FOR otherwise generalizes
>>      to LONGINT without change.
> 
> The current implementation does not permit the range values to be 
> different types (both must be INTEGER or LONGINT), and the step value 
> must also match.  Will we permit any mixing of values?  If so, I assume 
> that we use the maximal type of the expressions (LONGINT if any one is 
> LONGINT, INTEGER otherwise).
>

I think allowing mixtures here is going too far.  Moreover, the existing
rule for FOR already requires the same base type for the two bounds, unlike
the assignability rule for operators, so unless we change an existing
language rule here, this form of mixing is not allowed.

Note that the step value is "integer-valued" unconditionally, i.e.,
even if the bounds have, say, an enumeration type.  Taken literally, I
would say this would allow its type to be INTEGER, LONGINT, or any subrange
thereof.  Perhaps on a tiny 8-bit embedded processor, this could have
a use.

......................................................................


>> 22. There is a new required interface LongWord.  It almost exactly
>>    parallels Word, except 1) LongWord.T = LONGINT, and 2) it contains
>>    new functions ToWord and FromWord, that conversion between the two
>>    types, using unsigned interpretations of the values.  ToInt may
>>    produce a checked runtime error, if the result value is not in the
>>    range of an unsigned interpretation of INTEGER.
> 
> This is the current implementation, but we do not support ToWord and 
> FromWord.  Why do we need these?

All the operations in Word apply an unsigned interpretation to the bits
of the word, whereas the operators and functions in the language apply
signed.  Unsigned expansion is different(zero extend) from signed (sign
extend).  FromWord would do the unsigned, while VAL would do the signed.

Similarly, for contracting, the value range check is different.  Signed
means leftmost 33 bits all equal to each other.  Unsigned means leftmost
32 are all zero.

> 
>>      Word.T = INTEGER, so LongWord.T should = LONGINT, for
>>      consistency.  This means simple assignability tests and
>>      assignments between the types will use signed interpretations.
>>      So different functions are needed to do size changes with
>>      unsigned interpretation.
> 
> This is the current implementation.
> 
>