[m-rev.] for review: Fix codegen for subtype field names in high-level data grades.

[Peter Wang]

On Tue, 30 Apr 2024 19:27:00 +1000 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> On 2024-04-30 17:08 +10:00 AEST, "Peter Wang" <novalazy at gmail.com> wrote:
> > diff --git a/compiler/hlds_data.m b/compiler/hlds_data.m
> > index 4ba19cdf5..d53bd3362 100644
> > --- a/compiler/hlds_data.m
> > +++ b/compiler/hlds_data.m
> > @@ -982,11 +982,20 @@ set_type_defn_prev_errors(X, !Defn) :-
> >  :- type constructor_arg_repn
> >      --->    ctor_arg_repn(
> >                  car_field_name      :: maybe(ctor_field_name),
> > +                % car_maybe_base_arg says whether this constructor argument
> > +                % belongs to a subtype. If so, it must have a corresponding
> > +                % constructor argument in the base type, which may or may not
> > +                % have a field name.
> > +                car_maybe_base_arg  :: maybe_base_ctor_arg,
> >                  car_type            :: mer_type,
> >                  car_pos_width       :: arg_pos_width,
> >                  car_context         :: prog_context
> >              ).
> >  
> > +:- type maybe_base_ctor_arg
> > +    --->    no_base_ctor_arg
> > +    ;       base_ctor_arg(maybe(ctor_field_name)).
> 
> I intend to review the rest of this diff, but before I do, I would like
> to know why you chose this approach over the approach I thought
> would have been the obvious one, which would be to have the subtype
> inherit all the field names for its subset of data constructors from its supertype.

This was the obvious and direct fix to me. I just made the code work how
I expected it to work all along.

> One could either forbid the subtype declarations containing field names,
> or just forbid them from having field names that differ from the supertype,
> but either way, the supertype's field names would be available to be used
> both by programmers, and by the code generator.

I'm still intending on introducing restrictions on subtype field names,
but that's a language design issue.

> The approach used by the type definition above is more flexible than that,
> in that it allows subtypes to have (user-facing) field names that differ from
> the supertype's names for the same fields. What I would like to know is:
> in what kinds of scenarios would this capability be more helpful than confusing?
> The reason why I ask is that I can't think of any.

Perhaps:

- Adding distinguishing prefixes to field names. This makes more sense
  if you consider subtypes as distinct types first, that happen to be
  coerceable to other du types.

- Renaming a field for documentation reasons, e.g. from "maybe_foo" in
  the supertype to "foo" in the subtype.


BTW, does anyone know if there was particular reason for using Mercury
field names to derive field names in high-level data grades. Obviously
it makes for slightly more readable target code, but that seems like a
very small benefit.

Peter