[M3devel] INTEGER

[Tony Hosking]

This is bizarre, and perverts the language definition significantly more than the current scheme.
What is the base type of that subrange?

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