[M3devel] mixing INTEGER and LONGINT?

[Mika Nystrom]

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

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

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

    Mika