[M3devel] Correction: Re: [modula3/cm3] Packed set literal generation issue (#21)

[JC Chu]

>> 1) Although T and BITS n FOR T are are assignable to each other, BITS n FOR T and BITS m FOR T, (n#m) have no subtype or assignability relationship, so to assign one to the other would require two assignment steps, with a T as the intermediate type.
> 
> I had thought the above was true was true for a long time, but recently realized I was mistaken about that. Since <: is transitive, these two packed types are subtypes of each other, transitively through T, and thus mutually assignable.

This got me wondering, where is the subtyping rules for packed types?  The language definition, in §2.10, says specifically that, “for example, a record or array type with packed fields contains the same values as the corresponding type with unpacked fields, but there is no subtype relation between them”.

— JC


-----Original Message-----
From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] 
Sent: Sunday, October 22, 2017 9:14
To: m3devel <m3devel at elegosoft.com>; JC Chu <jcchu at acm.org>; Rodney Bates <rodney.m.bates at acm.org>
Subject: Correction: Re: [modula3/cm3] Packed set literal generation issue (#21)



On 09/23/2017 10:59 AM, Rodney M. Bates wrote:
> The following didn't come through the first time, at least not to me:
>
>
> Fixed on github, commit 12f50b4cde746056b943bd8aaa105c3fcb46b1a8
>
> Deleted the assertion, which is neither true nor needed.
>
> But see below:
>
> On 09/16/2017 11:54 PM, jcchu wrote:
>> See the fragment below.
>>
>> VAR r := SET OF [0..31] { 0 }; (* OK *)
>> s := BITS 32 FOR SET OF [0..31] { 0 }; (* -- assertion failure in “SetExpr.m3” *)
>
> Are you aware that the BITS 32 here has no effect on the size of the global variable?
>
> Quoting from 2.2.5, Packed types:
>
>   TYPE T = BITS n FOR Base
>
>   where Base is a type and n is an integer-valued constant expression.
>   The values of type T are the same as the values  of type Base, but variables of type T
>   that occur in records, objects, or arrays
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   will occupy exactly n bits and be packed adjacent to the preceding field or element.
>
> s is not inside a record, object, or array, so the BITS specification has no effect on
> the memory allocated by the compiler.
>
> There are, however some more obscure differences:
>
> 1) Although T and BITS n FOR T are are assignable to each other,
>    BITS n FOR T and BITS m FOR T, (n#m) have no subtype or assignability
>    relationship, so to assign one to the other would require two assignment
>    steps, with a T as the intermediate type.

I had thought the above was true was true for a long time, but recently realized
I was mistaken about that. Since <: is transitive, these two packed types are subtypes
of each other, transitively through T, and thus mutually assignable.

I haven't checked whether we have this implemented correctly.

>
> 2) Anywhere type equality, as opposed to assignability, is required, T and
>    BITS n FOR T will not match. For example, you cannot pass one of these to
>    the other as a VAR parameter.
>
>

-- 
Rodney Bates
rodney.m.bates at acm.org