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

[JC Chu]

My apologies; please ignore my previous message.  Obviously I misread the article: didn’t see the rules I was looking for and misinterpreted what I quoted.  :(

— JC


-----Original Message-----
From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] 
Sent: Monday, October 23, 2017 5:51
To: m3devel at elegosoft.com; JC Chu <jcchu at acm.org>
Subject: Re: [M3devel] Correction: Re: [modula3/cm3] Packed set literal generation issue (#21)



On 10/21/2017 10:18 PM, JC Chu wrote:
>>> 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”.
>

Not sure what you are asking here.  All the subtyping rules are in and only in 2.2.10.  \
The only ones specific to packed types are

BITS n FOR T <: T  and T <: BITS n FOR T

plus the general transitivity and reflexiveness of the relation.

The specific rules given ensure that every value of a subtype is a value of any
supertype, but types that satisfy this value inclusion rule are not necessarily
in the subtype relation.  The example of two records with corresponding fields
that have different types but one is a proper subtype of the other illustrates
this.  So does the example of AU and AT.

It would be a big implementation complexity if you could assign a record to a different
record type that was the same except for the bit packing of the fields.  That is
presumably why such records are not subtype-related.

> — JC
>
>
>
-- 
Rodney Bates
rodney.m.bates at acm.org