<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
I apologize for not paying close attention at the time.<BR>
That seems to make sense to me now.<BR>
<BR>
<BR>
There is at least an in-between version where INTEGER<BR>
is assignable to LONGINT.<BR>
<BR>
<BR>
In your proposal, the amount of source change required would be<BR>
I think very very little. Some code would "just work" with large files,<BR>
and some code would fail.<BR>
<BR>
<BR>
- Jay<BR><BR> <BR>> Date: Thu, 7 Jan 2010 19:35:20 -0600<BR>> From: rodney_bates@lcwb.coop<BR>> To: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] what to do about file sizes being 32bits?<BR>> <BR>> <BR>> I addressed all these details in my original LONGINT proposal, but it<BR>> didn't get much attention at the time. That would have been October<BR>> of 2007. I can't find the posts right now, because the link<BR>> http://mailarchive.elegosoft.com/Zope/m3/m3devel is broken, and I have<BR>> too many email account changes to be able to find it in my own<BR>> inboxes.<BR>> <BR>> I proposed, and still do, that LONGINT be an ordinal type. This has<BR>> the consequence, by preexisting rules, that INTEGER and LONGINT would<BR>> be assignable to each other. This does not violate the preexisting<BR>> language precedent, in fact, it is exactly like the preexisting rules<BR>> for INTEGER and all its subtypes--they are assignable if the value is<BR>> in the LHS type.<BR>> <BR>> This eliminates the necessity for the ORD and VAL conversions in most<BR>> places, where there are mixtures of the types. Most places in the<BR>> language require only assignability, not type equality. Exceptions<BR>> include passing to a VAR formal and use in a type definition of a new<BR>> type.<BR>> <BR>> A consequence of existing rules is that there would be, if necessary,<BR>> runtime value checks. In many cases, including the examples we are<BR>> discussing here, assigning a LONGINT to an INTEGER could well<BR>> introduce a bug when a value is out of range, but this is no different<BR>> from what happens when ORD/VAL are coded explicitly.<BR>> <BR>> On the other side of this argument, the necessity of coding ORD/VAL<BR>> would point out statically, places where value range errors should be<BR>> ruled out by the programmer. A conscientious programmer would then<BR>> make an informed decision whether to just insert ORD/VAL, or whether<BR>> it was necessary to change the INTEGER variable to LONGINT. But<BR>> again, the already existing rules for subranges don't do this, so<BR>> making INTEGER and LONGINT assignable would be consistent.<BR>> <BR>> Note that right now, the current implementation has a linguistic<BR>> contradiction in that, if subranges of LONGINT are allowed, then<BR>> LONGINT is an ordinal type, which implies LONGINT and INTEGER are<BR>> mutually assignable. This could, of course be fixed in the language,<BR>> but I would prefer making the two types assignable.<BR>> <BR>> <BR>> <BR>> <BR>> Jay K wrote:<BR>> > File.i3:<BR>> > <BR>> > <BR>> > Status = RECORD<BR>> > type: Type;<BR>> > modificationTime: Time.T;<BR>> > size: CARDINAL (* oops... *)<BR>> > END;<BR>> > <BR>> > <BR>> > What to do?<BR>> > [0.. higher than 7FFFFFFF] doesn't "just work".<BR>> > higher than 7FFFFFFFF is not legal on 32bit, unless you put "L" on <BR>> > the end,<BR>> > which presumably has some relationship to turning it into a LONGINT, <BR>> > which<BR>> > causes users to fail to compile<BR>> > <BR>> > <BR>> > LONGINT doesn't "just work"<BR>> > causes users to fail to compile<BR>> > <BR>> > <BR>> > stale imports -> compiling ProcessPosixCommon.i3<BR>> > stale imports -> compiling ProcessPosixCommon.m3<BR>> > stale imports -> compiling ProcessPosix.m3<BR>> > stale imports -> compiling FileRd.i3<BR>> > missing version stamps -> compiling FileRd.m3<BR>> > "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN<BR>> > "../src/rw/FileRd.m3", line 140: types are not assignable<BR>> > 2 errors encountered<BR>> > stale imports -> compiling FileWr.i3<BR>> > missing version stamps -> compiling FileWr.m3<BR>> > "../src/rw/FileWr.m3", line 92: incompatible argument types: MIN<BR>> > "../src/rw/FileWr.m3", line 108: incompatible argument types: MAX<BR>> > 2 errors encountered<BR>> > st<BR>> > <BR>> > <BR>> > Change it to LONGINT, fix all the callers, and hope the damage isn't too <BR>> > great outside the cm3 tree?<BR>> > <BR>> > <BR>> > Change it to LONGINT only for 32bit platforms, somehow author the cm3 <BR>> > tree to work either way,<BR>> > hope the damage isn't too great outside the cm3 tree?<BR>> > <BR>> > <BR>> > Change it to LONGREAL so that it works immediately on NT386.<BR>> > Same issues as above, breaks existing users.<BR>> > <BR>> > <BR>> > Maybe relax the language some, so that e.g.<BR>> > a:INTEGER;<BR>> > b:LONGINT;<BR>> > <BR>> > b := a;<BR>> > <BR>> > just works, see if it helps make more code compile with the change?<BR>> > <BR>> > a := b is problematic of course, but what is wrong with b := a?<BR>> > <BR>> > - Jay<BR>> > <BR> </body>
</html>