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

[Tony Hosking]

On 7 Jan 2010, at 20:35, Rodney M. Bates wrote:

> 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.

LONGINT *is* an ordinal type.  It just has a different base type than INTEGER so it is not subtype-related.

> 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.

The question really is what should the top type be?

We don't want to have all ordinal types base themselves on LONGINT because then they will all incur LONGINT operations (which may be more expensive than the "natural" INTEGER operations).

> 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.

I really don't see how to accomodate this within the Modula-3 type system and its existing rules.

Now, we could introduce an explicit rule that says INTEGER <: LONGINT.  Then we can freely assign INTEGER values to LONGINT values.

> 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.

Allowing assignment of LONGINT to INTEGER requires an implicit range check on assignment, but perhaps that is OK.

> 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.

In this case I prefer the need for explicit conversion just so that programmers are made aware.

> 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.

No, there is no contradiction in the current implementation.  It treats subranges of LONGINT as having base type LONGINT.   So they are unrelated to INTEGER based types.

> 
> 
> 
> 
> 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