[M3devel] INTEGER

[hendrik at topoi.pooq.com]

On Mon, Apr 19, 2010 at 02:44:00PM -0400, Tony Hosking wrote:
> 
> 
> On 19 Apr 2010, at 13:23, Mika Nystrom wrote:
> 
> > 
> > Well *my* problem is that I still use PM3 for a lot of things.  Trying to
> > switch to CM3, yes, but I can't "certify" CM3 for critical stuff yet.
> > 
> > So I'm maintaining a significant amount of code that needs to compile 
> > under both PM3 and CM3.  Two problems crop up.  
> > 
> > 1. If there are bugs in m3tk/stubgen, the fixes only apply to one or
> > the other version of m3tk/stubgen.
> > 
> > 2. Some of the code I'm maintaining processes Modula-3 code as input.
> > It needs to be in two versions.
> > 
> > In this kind of environment, programming languages don't really
> > evolve, since the system depends on their being both forward- and
> > backward-compatible.  They "change" is more correct.  The way Java
> > changes.  
> 
> Indeed: Growing a Language, by Guy Steele
> 
> > 
> > More in general, though, Modula-3's designers were clearly well acquainted
> > with C, Fortran, and other languages that provide different-range
> > integers.  They chose not to indulge.  I even have a version of Modula-3
> > for a 16-bit machine that doesn't do it, even though on this machine the
> > need for a 32-bit integer is arguably greater than the need for 64-bit
> > integers on 32-bit machines.  Now we indulge in this language complication
> > to solve what is clearly a temporary problem, since anyone who cares
> > about large problems is going to have 64-bit systems yesterday... and
> > meanwhile no one seems to have availed himself of the solution!
> 
> If we were to revert, I have no idea what the implications would be.  Jay?
> 
> > My worst fear is that once the process gets started, the reason for
> > staying with the original Green-Book specification has now been defeated
> > and we will see more and more "evolution".  Trying to actually build
> > systems that process Modula-3 like data becomes, at that point, like
> > trying to stand in quicksand.
> 
> Indeed!
> 
> > 
> > I'm not incredibly picky here... I just hope it doesn't go further.
> > I would personally support either sticking with the current status quo
> > or going back to the Green Book w.r.t. integers and characters.
> 
> Indeed, I would not want to see this go any further.  I am still not 
> sure I am comfortable with the LONGINT extension (even though I put a 
> lot of time into it).  There just seemed to be a lot of pressure for 
> it to so CM3 could handle large file indexes.  I've never been 
> convinced that WIDECHAR was a winner either -- it was a reflexive 
> action in the face of Java's Unicode.   The CM3 people were building a 
> Java VM above CM3 at the time.

The LONGINT problem has several causes:

(1) INTEGER being defined as the largest integer type in the language.
(2) INTEGER being implemented as a specific fixed-size type that can be 
implemented "efficiently", whatever that means.
(3) The world of Modula 3 programmers using INTEGER whenever they didn't 
want to worry about what actual range they needed.

These three facts make it difficult to implement integer types that are 
larger than the ones that are "efficient" on the hardware.

In my opinion it was a mistake to define the "efficient" integer type to 
necessarily be the "largest" integer type.

It was this that made it necessary to invent a new type hierarchy of 
LONGINTs, which are not necessarily implemented efficiently.  But I see 
no need to make the largest type in this hierarchy explicitly available 
to the programmer.  It is possible to have only subranges of LONGINT 
available, and it is possible to track the maximum values achievable 
with arithmetic operations, and thus determine the subranges needed for 
intermediate results.  Had we left LONGINT unconstrained, we could have 
had the simple rule: use INTEGER if efficiency is more important thatn 
correctness (or you know you'll be in-range), use LONGINT otherwise.

Doing that thoroughly would have required some compiler energetics.  
Still, the necessaries could all have been done statically, without 
causing any further grief the day a third length of integer is needed.  
I have no idea whether that day will ever arrive, but it seems foolish 
to design the language in such a way as to make that day difficult 
to accomodate.

My druthers would have been to have more-or-less the present 
LONGINT,  but restrict programmers to use only subtypes of it.   If 
there is to be a maximum LONGINT value (possibly as an implementation 
reastriciton), overflowing past it must be checked.

-- hendrik

> 
> > 
> > Saying that EWD wasn't renowned for his practicality is something he
> > would have taken as a great compliment, I'm sure.
> 
> ;-)
> 

Actually, I kind of suspect he thought he *was* being practical.

-- hendrik