[M3devel] Integers

[Rodney M. Bates]

hendrik at topoi.pooq.com wrote:
> On Thu, Jan 07, 2010 at 01:58:51PM -0500, Tony Hosking wrote:
>> I think your confusion relates to understanding how the language 
>> defines "base" types.
>>
>> You should understand that INTEGER and LONGINT have *different* base 
>> types.  This indicates that they have inherently different 
>> representations,
> 
> What's implicit in this statment is that all the subranges of INTEGER 
> have inherently the same representation.  Why is this inportant?  Are 
> there, for example,  places in the language where you have a subrange 
> but don't know what the subrange is?
> 

No, this is not implicit.  An implementation can (and probably should)
store a variable of a subrange type in a byte or two, if sufficient to
hold the range.  When the programmer assigns this to an INTEGER, the
compiler will have to make a representation change.  But is has the
necessary information to do this without huge trouble.

Similarly, the implementation _must_ store a subrange in a restricted
size field when it is a field or array element having a BITS type
derived from a subrange type.

What's unique about Modula-3 is that such representation changes are
left to the compiler, while the language merely views values as
sometimes belonging to more than one type, and allows such values to be
assigned when so.  The usual approach in other languages is to elevate
the representation change from a machine-level matter to a language-
level matter by treating it as an implicit type change in addition to
a representation change.  The result is always a lot of unnecessary
complexity in the language.

>> and indeed, operations on INTEGER and operations on 
>> LONGINT are inherently different.
> 
> So in the language at present, there is no single type at the top of the 
> integer type lattice (and it's not really a lattice).  There are, 
> however, two maximal types.  Is this right?
> 
>> Every enumeration type similarly has a base type.  If it's range is 
>> expressed over INTEGER values then its base type is INTEGER.  If 
>> expressed over LONGINT then its base type is LONGINT.
>>
>> I don't think I understand the rest of your questions.
> 
> Where in the language is it important that INTEGER and LONGINT be 
> different base types?  In other words, what advantages does this 
> separation convey?

One thing that is very much needed in a language (not the only thing)
is a type that always matches the implementation's native arithmetic
size, which is most efficient.  If you don't distinguish this type,
it becomes either impossible or horribly convoluted to define arithmetic
so native machine arithmetic can be usually used where possible,
but multi-word arithmetic will be used where needed.

> 
> -- hendrik
>> On 7 Jan 2010, at 11:46, hendrik at topoi.pooq.com wrote:
>>
>>> I have some questions as to the constraints that need to be placed on 
>>> integral types.  These issues are fundamental to an understanding of the 
>>> role of LONGINT, INTEGER, and CARDINAL, and what we should be doing 
>>> about them.
>>>
>>> Is there a need for an integer type that can contain all the sizes of 
>>> integers that can be handled by the language?  I'll call it TOP just so 
>>> I can talk about it easily.
>>>
>>> If it is necessary, is TOP only needed to make the language definition 
>>> clean and concise?  Conversely, is it necessary for TOP to be available 
>>> to programmers?  Is it necessary for TOP to be efficiently implemented, 
>>> or implemented at all?
>>>
>>> Even if it is not available directly to programmers, are there language 
>>> features that require it internally?
>>>
>>> Is it necessary that, for every two integer subranges I and J, there 
>>> exist an integer range K such that both I and J are subranges of K?
>>>
>>> The most commonly used integral type is INTEGER.  It seems to be the 
>>> type used by programmers by default when they don't want to think of 
>>> the specific range they will need.  But is it necessary for the type 
>>> called INTEGER to be TOP?  Or, is there is no maximum implemented 
>>> integral type, is it still necessary for INTEGER to be a maximal 
>>> integral type?
>>>
>>> -- hendrik
>