[M3devel] INTEGER

[Mika Nystrom]

"Rodney M. Bates" writes:
...
>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.

It is precisely my point that LONGINT is equally evil as INTEGER.
The language doesn't need two "evil" integer types.  If there is to be
another one (an inefficient one, to boot!) I think it had better offer
something that INTEGER does not (such as Hendrik's suggestion).

In fact since I have now seen it suggested that LONGINT be at least 64
bits wide, (correct) LONGINT-based code will be *less* portable than
(correct) INTEGER code, which is allowed to make no such assumptions and
hence has to work whether INTEGER is 16, 32, 36, or even 666 bits wide.

     Mika