[M3devel] mixing INTEGER and LONGINT?

[Tony Hosking]

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

> 
> 
> Tony Hosking wrote:
>> Let's have a clean language proposal before thinking about implementing it...  ;-)
>> I continue to oppose mixing operations on both LONGINT and INTEGER.  Just as one cannot mix REAL and LONGREAL.
>> I may accept checked assignability between INTEGER and LONGINT (after all, the bits are the same, its just a matter of how many are significant -- unlike REAL/LONGREAL/EXTENDED).
>> Looking further at the assignability rules:
>> A type T is assignable to a type U if:
>> 	• T <: U, or
>> 	• U <: T and T is an array or a reference type other than ADDRESS (This restriction is lifted in unsafe modules.), or
>> 	• 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.
> 
> I once considered adding this subtype relation as a way of not requiring the ORD/VAL coding,
> but it has some additional other consequences that I considered undesirable.  I don't
> remember what they were off the top of my head, but could no doubt reconstruct them,
> if anybody cares.

Right, I much prefer assignability rule 3, rather than a subtype relationship.

>> 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.
> 
> Yes, this is exactly what I am saying.  To require the ORD/VAL calls, we would have
> do one of:
> 
> 1) Say LONGINT is not an ordinal type.

Not necessarily.  See my definition of ORD/VAL in the update language spec.

> 2) Say that 10 and 10L are not only expressions of different types, but
>   also distinct values as well.  The low values of LONGINT and the
>   corresponding values of INTEGER would not be the same.

I don't think we need to say they are different values (in fact, they can be converted).  VAL(10, LONGINT) = 10L.

> 3) Alter the definition of assignability, for example to say in the third clause,
>   that T and U must have the same base type as well as a member in common.

In my definition both INTEGER and LONGINT *are* ordinal types so no need to change.

> Doing 1) Runs strongly against my intuitive sense of what "ordinal" means.  It would
> also mean there would be no subranges of LONGINT and probably eliminate several
> other things you might expect to come along with LONGINT.

Agreed.

> Doing 2) Seems like a big contradiction to the way subranges work and the existing
> Modula-3 philosophy of types sometimes having overlapping value sets.

Agreed.

> Which leaves 3), which I think is the only reasonable way to do this.

I don't see the need if both are ordinal types.  They have some values in common.  So they are assignable.

> If we leave this as is, it will follow that assignment statements and mixed arithmetic
> are legal and work the same way as with different subranges of the same base type.
> Given the liberal assignability rules we already have, I don't think this is
> necessarily a bad idea, despite my general bias toward requiring more stuff to
> be explicit in code.  There are about 8 or 9 places, as I recall, that would be
> affected because they require only assignability.

So, in the current implementation we just don't have assignability and mixed arithmetic.

> The definitions of the arithmetic operators would have to be treated with some care
> to avoid allowing or requiring that INTEGER <op> INTEGER be done in LONGINT machine
> arithmetic, something we absolutely must avoid.

Correct.

> This points out where the analogy
> to subranges does not apply to INTEGER/LONGINT.  With subranges, the only reasonable
> implementation is to expand the operands to the base type and do the arithmetic
> in that size.

But that is exactly how the current implementation works.

> Here, we don't want that to happen unless at least one operand is
> LONGINT.

So, the base type yields the correct behavior.

> On a side note, I do not believe the analogy to the floating types applies here.
> With INTEGER/LONGINT, there is a very obvious and natural equivalence between
> the values of INTEGER and the lower values of LONGINT.  Not necessarily so with
> different native machine floating types.  The messiness of floating representation
> means you can't assume the exactly representable reals are the same for two different
> floating types, even within some restricted value range.

Yes, that is why I am leaning in your direction: assignability plus mixed arithmetic.

> 
> 
> 
>> On 8 Jan 2010, at 02:44, Jay K wrote:
>>> This simple diff in the front end allows the "obvious" mixing of INTEGER and LONGINT without any need for ORD or VAL.
>>>   LONGINT + INTEGER => LONGINT   LONGINT - INTEGER => LONGINT   LONGINT * INTEGER => LONGINT   LONGINT DIV INTEGER => LONGINT   INTEGER DIV LONGINT => LONGINT (subtle and I think incorrect, should be INTEGER)   INTEGER MOD LONGINT => INTEGER (subtle but I believe correct)    LONGINT MOD INTEGER => INTEGER (subtle but I believe correct)    MIN(INTEGER, LONGINT) => LONGINT (This is wrong actually, should be INTEGER)    MAX(INTEGER, LONGINT) => LONGINT    LONGINT := INTEGER  Other mixes are less obvious and would require runtime checks.
>>> I think the backend will just work but I haven't tried that yet.
>>> (Truth be told, I can only affectively edit files on NT...)
>>> Thoughts?
>>> 
>>