[M3devel] INTEGER

[hendrik at topoi.pooq.com]

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