[M3devel] what to do about file sizes being 32bits?

[Rodney M. Bates]

I addressed all these details in my original LONGINT proposal, but it
didn't get much attention at the time.  That would have been October
of 2007.  I can't find the posts right now, because the link
http://mailarchive.elegosoft.com/Zope/m3/m3devel is broken, and I have
too many email account changes to be able to find it in my own
inboxes.

I proposed, and still do, that LONGINT be an ordinal type.  This has
the consequence, by preexisting rules, that INTEGER and LONGINT would
be assignable to each other.  This does not violate the preexisting
language precedent, in fact, it is exactly like the preexisting rules
for INTEGER and all its subtypes--they are assignable if the value is
in the LHS type.

This eliminates the necessity for the ORD and VAL conversions in most
places, where there are mixtures of the types.  Most places in the
language require only assignability, not type equality.  Exceptions
include passing to a VAR formal and use in a type definition of a new
type.

A consequence of existing rules is that there would be, if necessary,
runtime value checks.  In many cases, including the examples we are
discussing here, assigning a LONGINT to an INTEGER could well
introduce a bug when a value is out of range, but this is no different
from what happens when ORD/VAL are coded explicitly.

On the other side of this argument, the necessity of coding ORD/VAL
would point out statically, places where value range errors should be
ruled out by the programmer.  A conscientious programmer would then
make an informed decision whether to just insert ORD/VAL, or whether
it was necessary to change the INTEGER variable to LONGINT.  But
again, the already existing rules for subranges don't do this, so
making INTEGER and LONGINT assignable would be consistent.

Note that right now, the current implementation has a linguistic
contradiction in that, if subranges of LONGINT are allowed, then
LONGINT is an ordinal type, which implies LONGINT and INTEGER are
mutually assignable.  This could, of course be fixed in the language,
but I would prefer making the two types assignable.




Jay K wrote:
> File.i3:
> 
> 
>   Status = RECORD
>     type: Type;
>     modificationTime: Time.T;
>     size: CARDINAL (* oops... *)
>   END;
> 
> 
> What to do?
> [0.. higher than 7FFFFFFF] doesn't "just work".
>    higher than 7FFFFFFFF is not legal on 32bit, unless you put "L" on 
> the end,
>    which presumably has some relationship to turning it into a LONGINT, 
> which
>    causes users to fail to compile
> 
> 
> LONGINT doesn't "just work"
>    causes users to fail to compile
> 
> 
> stale imports -> compiling ProcessPosixCommon.i3
> stale imports -> compiling ProcessPosixCommon.m3
> stale imports -> compiling ProcessPosix.m3
> stale imports -> compiling FileRd.i3
> missing version stamps -> compiling FileRd.m3
> "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN
> "../src/rw/FileRd.m3", line 140: types are not assignable
> 2 errors encountered
> stale imports -> compiling FileWr.i3
> missing version stamps -> compiling FileWr.m3
> "../src/rw/FileWr.m3", line 92: incompatible argument types: MIN
> "../src/rw/FileWr.m3", line 108: incompatible argument types: MAX
> 2 errors encountered
> st
> 
> 
> Change it to LONGINT, fix all the callers, and hope the damage isn't too 
> great outside the cm3 tree?
> 
> 
> Change it to LONGINT only for 32bit platforms, somehow author the cm3 
> tree to work either way,
> hope the damage isn't too great outside the cm3 tree?
> 
> 
> Change it to LONGREAL so that it works immediately on NT386.
>   Same issues as above, breaks existing users.
> 
> 
> Maybe relax the language some, so that e.g.
> a:INTEGER;
> b:LONGINT;
> 
> b := a;
> 
> just works, see if it helps make more code compile with the change?
> 
> a := b is problematic of course, but what is wrong with b := a?
> 
>  - Jay
>