[M3devel] INTEGER

[Tony Hosking]

But this is bizarre.  What type does an element of a subrange of LONGINT have if not LONGINT?  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.  But then, values of the LONGINT subrange don't have the same representation as their INTEGER counterpart.

All very odd.

On 21 Apr 2010, at 14:56, hendrik at topoi.pooq.com wrote:

> On Wed, Apr 21, 2010 at 09:55:29AM -0500, Rodney M. Bates wrote:
>> 
>> 
>> Mika Nystrom wrote:
>>> Tony Hosking writes:
>>>> On 20 Apr 2010, at 13:12, Mika Nystrom wrote:
>>> ...
>>>>> easy access to the hardware in their own machines, not really so that =
>>>> IBM
>>>>> programmers could have an extra format for VAX compatibility.  Note =
>>>> that
>>>>> I don't believe that it was intended that EXTENDED would be emulated =
>>>> by
>>>>> the compiler either: the point was really to give programmers access =
>>>> to
>>>>> the formats provided efficiently by their hardware.
>>>> In the current implementation EXTENDED=3DLONGREAL.
>>> 
>>> Ok, but EXTENDED is still something that is efficiently provided by
>>> my hardware.  Not something efficiently provided by someone else's
>>> hardware!
>>> 
>>>>> 4. I still haven't seen any really convincing use cases.  What's it =
>>>> for?
>>>>> The lack of LONGINT was an obstacle to what, precisely?
>>>> I think the only one we have is file sizes...
>>>> 
>>>>> 5. Finally, is it the intention that LONGINT be fixed at 64 bits
>>>>> forevermore?  (See point 2.)  This seems to completely fly in the face
>>>>> of M3's philosophy.  (See Hendrik's arguments.)
>>>> The only constraint imposed is BITSIZE(LONGINT) >=3D BITSIZE(INTEGER).
>>> 
>>> I am not so sure here.
>>> 
>>> Rodney's argument has in fact convinced me that the current version of
>>> LONGINT is wrong and perhaps evil.  It should either go away completely
>>> or be replaced by Hendrik's suggestion.
>>> 
>>> Here's why.  The argument is that if I have an N-bit machine, for N<M,
>>> out there in the world there is an M-bit machine that for some reason
>>> matters a great deal to me.  For some reason I need to be able to write
>>> code that manipulates M-bit integers---because of the existence of this
>>> M-bit machine (or machines)!  
>> 
>> It has never been motivated by the existence of machines with various native
>> arithmetic sizes.  It is about problems that need big value ranges to work.
>> 
>> Its also about making it convenient to write portable code that solves
>> them. (Well, that part does have to do with the machines that exist.)
>> And making the type checking, etc. not change on the different machines.
>> And using the most efficient arithmetic consistent with correct answers.
>> 
>> Normally we're dealing with the situation
>>> that N=32 and M=64.)  So we introduce an M-bit LONGINT.  Now it stands to
>>> reason that if the M-bit machine (which I do not own and upon which my
>>> program does not run) is important to me, it is also important to other
>>> Modula-3 programmers.  Hence all other implementations of Modula-3 will
>>> *also* provide M-bit integers.  
>>> 
>>> The M-bit machine of the previous paragraph is of course, in the real
>>> world, a machine with the 64-bit version of the Intel x86 instruction set,
>>> "amd64".  How long is it from here to the point where we have programmers
>>> who write code that depends on the fact that M=64, always?
>> 
>> LONGINT presents the same opportunity/invitation/temptation to
>> write code that make such assumptions as does INTEGER, or for that matter,
>> REFANY, or gobs of other things in the original language.  So LONGINT is
>> just as evil as INTEGER.
> 
> Which is why I'd allow only subranges of LONGINT to be mentioned in 
> programs.
> 
> -- hendrik
> 
>> 
>>> 
>>>    Mika
>>> 
>>>