[M3devel] INTEGER

[Tony Hosking]

Defined as...

On 22 Apr 2010, at 11:43, hendrik at topoi.pooq.com wrote:

> On Thu, Apr 22, 2010 at 03:27:50PM -0400, Tony Hosking wrote:
>> This is bizarre, and perverts the language definition significantly more than the current scheme.
>> What is the base type of that subrange?
> 
> LONGINT.
> 
> -- hendrik
> 
>> 
>> On 22 Apr 2010, at 10:55, hendrik at topoi.pooq.com wrote:
>> 
>>> On Thu, Apr 22, 2010 at 02:36:17PM -0400, Tony Hosking wrote:
>>>> Let me see.
>>>> 
>>>> The green book definition says the base type of a subrange of INTEGER literals is INTEGER.
>>>> You say that the base type of a subrange of LONGINT literals is LONGINT.
>>>> But you say that LONGINT is not a defined type.  So, what is the type 
>>>> of a LONGINT literal?
>>> 
>>> (a) 3849587394875493920398438483929293484L could very well be of type 
>>> 3849587394875493920398438483929293484L..3849587394875493920398438483929293484L
>>> which is a one-element subtype of LONGINT.
>>> 
>>> LONGINY is a type.  It's just one that's not available directly to the 
>>> programmer.  It would not need to have a defined size, if the language 
>>> allowed LONGINT values to occur *only* where an upper bound on 
>>> their size is known, such as by being elements of a subrange.
>>> 
>>> -- hendrik
>>> 
>>>> 
>>>> [I think I misunderstood you previously. I had interpreted that you meant LONGINT subranges to have base type INTEGER.]
>>>> 
>>>> On 22 Apr 2010, at 08:38, hendrik at topoi.pooq.com wrote:
>>>> 
>>>>> On Thu, Apr 22, 2010 at 11:57:16AM -0400, Tony Hosking wrote:
>>>>>> But this is bizarre.  What type does an element of a subrange of 
>>>>>> LONGINT have if not LONGINT?
>>>>> 
>>>>> It has LONGINT as a type.
>>>>> 
>>>>>> If the subrange has a base type of INTEGER then we need a mapping 
>>>>>> between the elements of the subrange and the base INTEGER values.
>>>>> 
>>>>> Yes.  And INTEGER is different from the notion mathematicians have of 
>>>>> integers in that there is a limit on the size of integers.  It's a 
>>>>> machine or implementation-dependent limit, and it's imposed for 
>>>>> efficiency reasons, but it's a specific limit just the same.
>>>>> This limit is precisely what we're up against.
>>>>> 
>>>>>> But then, values of the LONGINT subrange don't have the same 
>>>>>> representation as their INTEGER counterpart.
>>>>> 
>>>>> Of course not.  If they did have the same representation, there would be 
>>>>> in-range for INTEGERs, and there would be no need to have LONGINT at 
>>>>> all.
>>>>> 
>>>>> LONGINT is there precisely for the integers that *don't* fit in INTEGER.
>>>>> 
>>>>>> 
>>>>>> All very odd.
>>>>> 
>>>>> But dictated by the intended use -- that of having integral ranges
>>>>> whose bounds are dictated by the problem, not the hardware.
>>>>> 
>>>>> -- hendrik
>>>> 
>>