[M3devel] the LONGINT proposal

[Tony Hosking]

Hi Randy,

As someone who has actually written Modula-3 programs for a living your opinions are always highly valued.  I agree with you in principle and aims, except for requiring overflow to be a checked run-time error.  The language definition already has a mechanism for handling this in the require FloatMode interface.  It is not something that the compiler should be involved in.  I also just now raised a question about perhaps having integer literals adapt their type to the context in which they are used.

I should point out that the current mainline implementation does exactly what you propose (except overflow checking).  It captures the fundamental spirit of Rodney's proposal but does not permit mixed arithmetic or assignment.  Can I ask what your issue is w.r.to checked assignability?  I am still leaning in favor.  It is not much different from assignment from an INTEGER to a subrange, which requires no explicit check, though of course there is a run-time range check.  Having programmers explicitly write:

x: INTEGER := ORD(longint, INTEGER);

seems unnecessary when they could just write

x: INTEGER := longint;

This is similar in spirit to:

x: [lo..hi] := integer;


On 10 Jan 2010, at 15:00, Randy Coleburn wrote:

> I've been trying to follow along on this topic.
> 
> Here are my thoughts:
> 
> 1.  LONGINT should be a distinct type different from INTEGER.
> 
> 2.  There should be no mixed arithmetic between the types.  The programmer must code conversions using ORD/VAL to make explicit the intention.  Don't rely on some ill-remembered built-in conversion rule.
> 
> 3.  Overflow should be a checked run-time error, not silently wrapped around.
> 
> 4.  WRT assignability, I think explicit conversions should be used.
> 
> These statements may make me unpopular with some who don't like to type much, but I've always hated the tradeoff of understandability for brevity in expression.
> 
> The important thing is not how fast we can type up a program, it is rather how hard is it to make a mistake.  I think the spirit of Modula-3 is that the language makes you a better programmer by forcing you to make your intentions explicit rather than relying on the compiler to infer your intentions.  We need correct and maintainable software, especially at the systems level.  Whatever is decided about LONGINT, we need to keep to the original design tenants of the language.  
> 
> And yes, I do think we need a LONGINT type, not just to deal with large file sizes.
> 
> But even for long-lived readers/writers, whatever type you choose for the index will eventually be insufficient, so you have to code for the possibility that the range of the long lived reader/writer exceeds the range of your index type.  That is just good programming.
> 
> I think sometimes that the new generation of programmers has been warped by what I call the "Microsoft Mentality" where you must expect that you need to reboot/restart every so often to maintain proper performance.  Programs should be written to run forever or until their job is completed or they are commanded to stop.  
> 
> As "we" begin to converge on the design changes, I like having something concrete to look at, ala Rodney's proposal.  Can we take that and keep tweaking it in these emails until we reach a final version acceptable to all?  To me this keeps the discussion focused rather than the many different emails.  Thus, what I am trying to say is put forth a numbered proposal and each subsequent email must show adjustment to that proposal rather than just a bunch of emails discussing various aspects.  Perhaps we should vote on each proposed change, then decide to call a final vote on the whole thing.  Who should be involved in such votes?  Right now the main persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.
> 
> My two cents.
> 
> Regards,
> Randy Coleburn

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