[m-dev.] two bugs in rotd compilers

Zoltan Somogyi zoltan.somogyi at runbox.com
Sat Mar 30 11:31:10 AEDT 2024


On 2024-03-30 11:21 +11:00 AEDT, "Peter Wang" <novalazy at gmail.com> wrote:
>> 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.

That will work. It basically leaves it up to the programmer to choose
between way one and way two, on a per-field basis.

I am however unsure how useful this extra freedom is compared
to requiring users to make the same choice for all fields in a given
type definition, or the system just imposing the choice wholesale.
I certainly can't think of a situation in which I would chooto se
keep the existing field name for one field but choose
no field name for another field.

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

Thank you.

Zoltan.


More information about the developers mailing list