<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
> 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.<BR>> <BR>> 4. WRT assignability, I think explicit conversions should be used.<BR>> <BR>
<BR>
Have you seen the resulting diffs?<BR>
<BR>
<BR>
Would we just say, that the initial rd/wr interface was so wrong, that there<BR>
is a lot of "incorrect" code, so the ugly diff is the result?<BR>
That newer code wouldn't be so initially wrong, so would remain not so ugly?<BR>
Maybe.<BR>
<BR>
<BR>
VAR a:LONGINT;<BR>
b:INTEGER;<BR>
INC(a, b);<BR>
<BR>
<BR>
doesn't that make perfect sense to even the most casual reader?<BR>
Many current proposals don't allow it.<BR>
Though Randy's does allow it.<BR>
<BR>
<BR>
Indexing by LONGINT is also trivial.<BR>
Just do the usual range check and go.<BR>
Indexing by INTEGER also has a range check.<BR>
One difference would be that a subrange of LONGINTs that are all greater than LAST(INTEGER) could be a stack error, just as some indexing by INTEGER subranges can also be a static error (e.g. if the array element size times the all the elements of the subrange or enum are larger than the address space).<BR>
<BR>
<BR>
> We need correct and maintainable software, especially at the systems level<BR>
<BR>
Nearly all systems level software is written in a language or languages that manage to zero extend or sign extend integers to wider integers.<BR>
The Modula-3 compiler/runtime/garbage collector is the biggest exception I can think of, but so far it can't really handle large files.<BR>
<BR>
<BR>
- Jay<BR><BR> <BR>> From: rcolebur@SCIRES.COM<BR>> To: m3devel@elegosoft.com<BR>> Date: Sun, 10 Jan 2010 15:00:58 -0500<BR>> Subject: [M3devel] the LONGINT proposal<BR>> <BR>> I've been trying to follow along on this topic.<BR>> <BR>> Here are my thoughts:<BR>> <BR>> 1. LONGINT should be a distinct type different from INTEGER.<BR>> <BR>> 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.<BR>> <BR>> 3. Overflow should be a checked run-time error, not silently wrapped around.<BR>> <BR>> 4. WRT assignability, I think explicit conversions should be used.<BR>> <BR>> 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.<BR>> <BR>> 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. <BR>> <BR>> And yes, I do think we need a LONGINT type, not just to deal with large file sizes.<BR>> <BR>> 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.<BR>> <BR>> 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. <BR>> <BR>> 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.<BR>> <BR>> My two cents.<BR>> <BR>> Regards,<BR>> Randy Coleburn<BR> </body>
</html>