[M3devel] Integers

[Tony Hosking]

On 7 Jan 2010, at 23:03, 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?

A subrange always has a known base type.

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

Correct.  Here is the subtype rule for ordinals:

For ordinal types T and U, we have T <: U if they have the same base type and every member of T is a member of U. That is, subtyping on ordinal types reflects the subset relation on the value sets.

Currently, we have two possible base types for ordinals: INTEGER and LONGINT.  They are distinct, unrelated types.

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

It conveys specific information about what specific machine values and operations implement them.  They can (and usually do) require different code to operate on them.  From a programmer's perspective, I know that every operation on INTEGER base values will involve *natural* integer arithmetic.  For LONGINT I am much less sure, and may require even calling a library to perform the operation (if the machine doesn't naturally support LONGINT).

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

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