[m-dev.] two bugs in rotd compilers

[Peter Wang]

On Fri, 29 Mar 2024 02:00:46 +1100 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> I don't think this issue has come up, since the subsection in the manual (4.2.4)
> says nothing about field names.
> 
> I can see three ways forward.
> 
> Way one: forbid field names in subtype definitions.
> Way two: allow field names in subtype definitions, but ONLY if they
> repeat exactly the field names in the supertype (and hence by transitivity,
> in the base type).
> Way three: allow field names in subtype definitions, even if they differ
> from the supertype.
> 
> I strongly dislike way three, but I am ok with ways one and two.
> However, whatever we pick
> 
> - has to be documented in the manual, and
> - has to be enforced by the compiler.
> 
> I can do both those things, once we have consensus on the
> way selection.

Indeed, there is not any restriction placed on subtype field names.

Previously, we did not allow duplicate field names in the same module
so it made no sense to require duplicate field names in subtype
definitions.

Now we allow duplicate field names in the same module, but some users
may prefer to add distinguishing prefixes to field names in subtype
definitions, or give different names to fields in a subtype.

Perhaps this restriction is sufficient: a subtype definition can only
have a field name that duplicates one of the field names in the
supertype definition (principal type constructor) *if* that name
labels the same constructor and argument position in both type
definitions.

> 
> All three ways also need the MLDS code generator to be fixed.
> I can see two possible approaches for the fix. One is ensure that we use
> the base type's field names to get access to the values of the fields
> in subtypes. The other is to ensure that the value of every field
> can be accessed using the protocol we use for unnamed fields
> even if the field has a name. Not knowing Java or C# well,
> I don't know which approach would be easier.
> 
> Peter, since you did the original subtype implementation,
> you know the code involved here the best. Do you have some time
> you can spare to work on this fix?

I'll see if I can look at it next week.

Peter