[m-rev.] for pre-review: deleting abstract_inst

[Zoltan Somogyi]

This is an incomplete diff, and I am seeking your opinions
on how to complete it. (It already bootchecks; that is not the issue.)

The most significant effect of this diff is that inst_lookups, when given
an user_inst inst_name insided a defined_inst term, will now abort
the compiler . It *used to* just return an abstract inst. Many parts of
the compiler attempted to do *something* with those abstract_insts,
though some other parts just aborted when they found them.
This makes it even more important detect all references to invalid insts
before we start mode analysis (since that is when inst_lookups start).

I added code to add_mode.m (which also adds insts) to diagnose
such references, but found that module qualification has already done so.
The question I have for you is:

- should we rely just on module qualification,
- should we instead use code like the one that this diff adds to add_mode.m,
  to diagnose references to undefined insts/modes in other entities,
  such as mode declarations,
- or should we use one approach for undefined insts/modes in some
  constructs, such as inst and mode definition, and the other for
  undefined insts/modes in other kinds of constructs?

The advantages of relying exclusively on module qualification is that
it already exists, and it generates all its messages in a uniform format,
which is therefore easy to learn.

The disadvantage is that the error messages generated by the new,
bespoke code in add_mode.m look to be better. You can see this
in the updated .err_exp file for the kind test case, in which some of
the errors have two error messages: one generated by module
qualification, and one generated by add_mode.m.

My feeling is that we should rely on module qualification, but
modify it to generate somewhat more descriptive error messages,
such as the ones now generated by add_modes.m.

This would mean throwing out some of the new code in add_mode.m.
I wanted to get agreement on this approach before I do so,
because I am guessing that if I implemented this approach without
asking you guys first, Murphy's law would ensure that I get a review
comment asking for that deleted code back :-(

Zoltan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Log.noabs
Type: application/octet-stream
Size: 4476 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20230720/3abb26c7/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DIFF.noabs
Type: application/octet-stream
Size: 92238 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20230720/3abb26c7/attachment-0003.obj>