[M3devel] mixing INTEGER and LONGINT?

[Tony Hosking]

On 8 Jan 2010, at 12:34, Mika Nystrom wrote:

> Tony Hosking writes:
> ...
>> A type T is assignable to a type U if:
>> 
>> 	=95 T <: U, or
>> 	=95 U <: T and T is an array or a reference type other than =
>> ADDRESS (This restriction is lifted in unsafe modules.), or
>> 	=95 T and U are ordinal types with at least one member in =
>> common.
>> 
>> This suggests that we don't really need to say that INTEGER <: LONGINT.
>> 
>> We can simply rely on the third clause regarding their both being =
>> ordinal types with at least one member in common.  Then assignment =
>> simply needs to test that the values are in range.
>> 
> 
> Are you sure about this for INTEGER and LONGINT?  I.e., are 0 and 0L
> the same "member"?

Yes, we could potentially do that.  It is straightforward because their significant bits are the same.

> By a similar argument, you could make REAL and LONGREAL assignable.
> Are 0.0d0 and 0.0e0 the same "thing"?  (On almost all machines they have
> the same bit patterns, same as 0 and 0L for that matter, and I can add
> that the way you do single-precision floating point on Alpha is by zeroing
> a big chunk in the middle of your double-precision fp registers...)

Not so reasonable, because their bits are different and need explicit conversion.

> I think I am with you on removing LONGINT from the language.  The proper
> way of handling file sizes (or anything else that might be a bigger number
> than a machine word) is through abstraction.  I have a suspicion that it's
> probably a severe micro-optimization to worry about the efficiency of
> operations on file sizes.  The thought that someone is adding automatic
> type conversion to Modula-3, a la C, makes me feel slightly sick to
> my stomach...

I agree with those sentiments.  While LONGINT can be accomodated (and more elegantly if we evolve towards Rodney's proposal -- see my other e-mail) I am still not convinced that it is worth all the complications.  If LONGINT is there only for large file sizes then abstraction is a *much* better way to go.  Why add a general-purpose type for a one-off use-case?

> I confess that my position is influenced by the fact that I have written
> many programs that generate Modula-3 code as an "intermediate language".
> I really really really need M3 to be easy to understand to get this to
> work well.  Also being able to parse interfaces and know precisely what
> they mean is important to me.  If the rules start getting sloppy.. that
> would really upset me.  On the other hand this means that if I'm faced
> with a problem that doesn't really fit into M3 well, say, working in
> arithmetic mod 2^(wordsize), my first instinct is not to demand changes
> to the language definition but to write a code generator that takes
> appropriate infix (or maybe more likely prefix) code and turns it into
> the appropriate calls through the Word interface.  It's a pain, yes, 
> but in the long run that's the right way, because you can do so much
> more with that approach than just unsigned integers.

Agreed.