[M3devel] LONGINT, my original proposal

[Tony Hosking]

Actually, that doesn't make sense -- it is an empty subrange.

On 9 Jan 2010, at 17:45, Tony Hosking wrote:

> Do you recall why CARDINAL is defined to behave like [0..LAST(INTEGER)]  instead of [0..16_FFFFFFFF]?
> 
> 
> 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
> 
> 
> 
> 
> On 9 Jan 2010, at 17:15, Rodney M. Bates wrote:
> 
>> 
>> 
>> 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.
>>> 
> 

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