[m-rev.] for post-commit review: move more pred name creation to pred_name.m

[Peter Wang]

On Tue, 15 Feb 2022 19:53:07 +1100 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> For review by anyone.
> 
> I would like to embed in item_xyz_infos that contain sym_names
> that that the parser implicitly quantifies (if the source code did not
> do so explicitly) the fact that that these sym_names can never be unqualified.
> I can do this either by replacing each sym_name with a module_name
> and string pair, or by using a subtype of sym_name, named possibly
> qual_sym_name, that rules out unqualified sym_names. The latter
> would be the first use of subtypes in the compiler, but it is
> semantically nicer.
> 
> Peter: I asked a while ago whether you think subtype support
> is ready for this, but I don't remember a clear answer. Can you
> please tell us whether subtype support has been exercised enough,
> and its design is stable enough, for us to rely on it?

I don't intend to make any changes to the design. If someone else wanted
to extend the design, I don't see any reason why basic usages like this
should be affected.

I can't say we've exercised subtypes much. I did try them out on a
Prince branch shortly after implementing subtypes, which was fine,
but to commit to it we'd need to do a company-wide update of the Mercury
compiler, which we haven't done yet. Then I forgot about it as I was
busy with other stuff.

But now I've checked that branch with a more recent compiler and
encountered a regression with writing out `coerce' expressions to .opt
files :( I will report or fix it separately.

Aside from that, I do think we can start using subtypes in the compiler.
And I should have time soon to instigate a compiler upgrade at YesLogic.

Peter