[M3devel] mixing INTEGER and LONGINT?

[Tony Hosking]

Once more summarising the discussion so far.

*If* we accept that LONGINT should stay then I agree we should implement Rodney's proposal (the current implementation + assignability between INTEGER and LONGINT + mixed arithmetic).

The question remains: is LONGINT necessary or simply a kludge better satisfied by arbitrary precision arithmetic like BigInteger.T?

On 8 Jan 2010, at 14:42, Rodney M. Bates wrote:

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