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

[Peter Wang]

On Thu, 20 Jul 2023 06:43:10 +1000 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 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.

The shorter error messages from the existing compiler seem fine to me.
Actually, I do prefer this:

    kind.m:027: In definition of inst `fi'/0:
    kind.m:027:   error: undefined inst `f9'/0.

over this, where the important parts are a bit harder to pick out:

    kind.m:027: Error: the definition of the inst constructor `fi'/0 refers to the
    kind.m:027:   inst constructor `f9'/0, which has no definition.

Peter