[M3devel] mixing INTEGER and LONGINT?

[Rodney M. Bates]

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"?
> 
> 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 agree, I hate the horrible complexities of implicit type conversions
in other languages.  But this doesn't have to be done by automatic type
conversion, just another instance of Modula-3's existing superior concept of
assignability between non-disjoint types.

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

In my original proposal, I said:
-------------------------------------------------------------------------
This proposal satisfies (I believe) the following principles:

The static correctness and type analysis of existing code written to
the current language definition will not change with the new
definition.  This also implies that the new language definition will
not introduce new type mismatches that would make existing pickles
unreadable.

The runtime semantics and time and space efficiency of existing code
written to the current language definition will also not change with
the new definition, if the native word size of the implementation does
not change.  Of course, porting existing code to an implementation
with different native word size can change the runtime semantics by
changing the supported value range, with or without language change.

The static type analysis of programs written to the modified language
definition will be independent of the implementation, particularly, of
the native word size.  This prevents inadvertently writing code that
is highly nonportable among different native word sizes.

The new, not-necessarily-native integer type does not extend to
certain existing uses of INTEGER and CARDINAL that are of unlikely
utility and would add complexity.


-------------------------------------------------------------------------

I still believe we can do these things, and also that the changes
to the language are not too drastic.  They are mostly just more
instances of existing concepts.