[M3devel] INTEGER

[Mika Nystrom]

"Rodney M. Bates" writes:
>The designers of Modula-3 gave use not one but three floating point types.
>They explicitly justified this as matching the range of hardware arithmetic
>provided by set of common processors of the day.
>
>They didn't say this (to my knowledge), but one integer type also matched
>the hardware of the day.  But the period when practically all processors
>had the same word size was a historical anomaly.  It was a nice halcyon
>time in that respect, and it allowed us to avoid some messy problems.
>
>But it never was true prior to that era, and it is no longer true.
>I doubt it will be again.  Despite the proliferation of 64-bit
>machines, there will be useful 32-bit ones around for a years.
>Not everybody buys the newest every three years, and 32 bits is
>still capable of a lot.  I don't see them being retired at anything
>like the rate 16-bit machines were, because they don't suffer the
>limitations.  And then we have the proliferation of embedded and
>hand-held devices, which as I am hearing, are already well out ahead
>of server and desktop computers in raw processor count.
>
>So I think keeping two integer sizes in the language removes what
>many people would consider a serious obstacle.  Moreover, the way
>the two integer sizes is are now defined is cleaner than I have
>seen in any other language.  It also somewhat follows the way the
>three floating types were done in the original language in that
>it preserves the type-uniqueness of every expression.  It further
>makes the static legality and semantics of code as close to
>implementation-independent as it was in the unmodified language.
>And it does not change the legality or static semantics of any
>old code.

I agree LONGINT isn't horrible.  However, I am not sure I agree
with your description above.

1. Modula-3 provides three floating-point formats because *each* common
processor architecture provided (and provides) support for generally at
least three floating-point formats.  The point was to give programmers
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.

2. 64-bit machines don't actually get two different integer formats
with the way LONGINT works.  INTEGER and LONGINT are both 64 bits.
That was not the intention with the floating-point formats either.

3. 64-bit machines were hardly unforeseen by DEC's research people,
given that their company introduced Alpha just after Modula-3 and that
DECWRL across town was working on 64-bit ECL machines.  In fact I think
Modula-3 had versions with 64-bit INTEGERs already in 1992?  (To use
Jay's expression, it's now 18 years later, and many C environments still
haven't caught up---int is still 32 bits in many of them!)  People at
SRC surely had a lot of 64-bit machines with Modula-3 programs running
on them in the early 90s.  Somehow the problem of representing 64-bit
integers on older VAX, MIPS, i386 systems just didn't arise for them?

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?

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

    Mika