[M3devel] Mixed arithmetic

[Jay K]

The limited range of efficient integers will always be a problem.

 

 

After all, in the real world, there is no such thing as LAST(INTEGER), nor the notion that + can fail, but even in Modula-3 we have both of these unfortunate things for efficiency.

 

 

It is a wierd system already.

 

 

Having LAST(INTEGER) + 1 fail or be FIRST(INTEGER) but LAST(INTEGER) + 1L provide a more sensible result I'm skeptical makes it any worse or wierder than it already is.

 

 

On the other hand, rd/wr/file ugliness is also fairly unavoidable, and just would have been there from the start had things been done right.

 

 

It is the unavoidable case that "large" files, even if they do fit in address space, are hard to deal with efficiently. Programmers are very used to efficient random access and often don't design for sequential access. And heck, with the rise of SSDs replacing spinning magnetic disks, it isn't going to matter any longer anyway.

 

 

 - Jay
 


From: hosking at cs.purdue.edu
Date: Mon, 11 Jan 2010 21:18:00 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] Mixed arithmetic




On 11 Jan 2010, at 20:21, Jay K wrote:




rather than having things

happen behind the scenes, without the programmer's coding them


Just a reminder that things happen behind the scenes *all the time*.
It is the norm, not the exception.
Look at what "try" does.

 It is two or three function calls.



Conceptually it need not be.  Moreover, the effects are not something the programmer needs to reason about.


Look at the garbage collector. 



Again, that is not visible to the programmer.  Same again re programmer reasoning.


Look at layering in various places.
The system is not simple.
This isn't a bad thing necessarily.
Getting things done often requires complexity.
I haven't finished listening to "growing a language" but Steele makes the point that if your language is too small, it is very limiting in what you can elegantly do or do at all.



His conclusion is interesting, and reflects the decision to grow Java not by language extension but by library extension.


Promoting an INTEGER to a LONGINT is among the simplest things you can do probably.




It is simpler in fact than adding 1 to an integer, because it cannot fail, whereas adding 1 can.

Let's enumerate some complexity.


What does LAST(INTEGER) + 1 mean?
What about LAST(INTEGER) + 1L?


Why should they mean something different?  Let's assume that it's all just values.  Then we want the same interpretation for both expressions.  But we must live in the real world where the meaning of "+" must be implemented using the limited integer range of the machine.


I think that the status quo is a reasonable place to be.  Yes, it means that you have to write VAL(LAST(INTEGER), LONGINT) + 1L to get something different than LAST(INTEGER)+1, but at least it retains referential transparency.


I strongly support the status quo.

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100112/50f52f29/attachment-0002.html>