[m-dev.] allowing duplicate field names in module

[Zoltan Somogyi]

2021-04-20 15:14 GMT+10:00 "Peter Wang" <novalazy at gmail.com>:
> What are the reasons that field names are required to be unique within a
> module, and not just within a type?
> 
> AFAIK, it's because if the user wanted to supply type/mode declarations
> for multiple fields with the same name, the generated functions would
> conflict. That doesn't seem like a strong reason to me; the compiler
> can just report the conflict.
>
> The reason I'm bringing this up is that it seems annoying to have to
> invent new field names when declaring subtypes, though obviously
> it's not limited to subtypes.

I agree with your concern in your third paragraph; I am also against
this limitation. Before we started work on Mercury, I was mostly a C programmer,
and so I was familiar with the game of picking a unique prefix for the names
of the fields of each struct, and wanted to avoid that for Mercury.

The reason Mercury nevertheless still requires this is not the reason
surmised in your second paragraph.

I remember a conversation I had with Fergus over this exact issue.
I remember it because it was one of the few times that it seemed that
I couldn't even make Fergus understand my point, much less accept
its validity. He was writing the typechecker at the time, one of whose
jobs is of course disambiguation. The names of predicates and types
are module qualified, and in his design approach to the typechecker,
the function symbols inside types were module qualified as well
(hence the prohibition on two function symbols in the same module
having the same name/arity pair). I tried to convince him that function
symbols should be *type* qualified, i.e. they should be qualified by
the identity of the type whose definition they belong to, and the
module qualification should be on the *type's* name, not on the
function symbols, specifically to avoid this limitation, but I don't he
understood me. (In retrospect, he was probably quite tired at the time.)
Or, maybe he did understand, and just didn't want to do the extra work
required to handle function symbols differently from predicates and types.
(Evaluable functions did not exist yet.) I couldn't overrule him, because
this happened at a time when nearly all the programming work on the
Mercury compiler was done by Fergus and Tom, because I had
far too heavy a teaching load to make major contributions in that area.

This design approach is why the cons_table in the module_info
has full hlds_cons_defns as values. If it were up to me, the cons_table
would be nothing more than map from function symbol names
to the list of type_ctors whose definitions include a function symbol
with that name. Over the years, I made small steps in that direction,
but the fundamental design of the typechecker means that any
attempt to make function symbols type qualified requires *lots* of work.

Zoltan.