[m-rev.] for review: move pred_origins closer to being a structured pred name

[Zoltan Somogyi]

For review by anyone.

I intend to continue working on this, so in the absence of a review
by then, I intend to commit this at about midnight, and address
any comments post-commit.

My intended next steps are as follows; I welcome comments on these
as well.

1. I intend to see whether giving names to type-specialized predicates
   and functions, which is now done during parsing (when the relevant
   pragma item is constructed) can be delayed until adding the pragma
   to the HLDS. This should allow pred_name.m, which is currently
   in the parse_tree package, to be moved to the HLDS package.

2. I intend to move the pred_origin type and its components to a new module.
   Only a few modules would have to import it, and only those few modules
   would need to be recompiled if it changes. Since the purpose of these
   changes is to turn the pred_origin type into a structured pred name,
   the logical name for the new module would be "pred_name.m". If step 1 above
   works, pred_origin can be added to pred_name.m. If it doesn't, we would
   need to put it into another module termporarily, maybe named pred_origin.m,
   until pred_name.m is eventually subsumed by new code using the moved
   pred_origin type.

3. I intend to rename pred_origin to something like structured_pred_name,
   which better expresses its new purpose. If anyone has a better name,
   please propose it.

4. I intend to refactor the pred_origin type so it has five function symbols

   - one for user defined predicates and functions
   - one for compiler defined predicate and functions that users can possibly
     explicitly refer to, such as mutable getters and setters
   - one for compiler defined predicate and functions that users cannot
     explicitly refer to, such as those implementing lambdas
   - one for compiler defined predicate and functions that result from
     the transformation of another *predicate*
   - one for compiler defined predicate and functions that result from
     the transformation of another *procedure*

   The reason for the refactor is that several parts of the compiler care about
   only one, or a few, of these categories, and listing the other categories in
   the relevant switches is both simpler and requires less maintenance than
   listing all the other pred_origins.

   The distinctions inside each category would of course be specified by
   values of new types.

   The distinction between "transform of a predicate" and "transform of
   a procedure" would allow the proc_id to be factored out of the existing
   pred_transform type (many of whose values actually describe transforms
   of *procedures*).

Zoltan.                                                         
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Log.po
Type: application/octet-stream
Size: 3593 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20220719/8963f755/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DIFF.po
Type: application/octet-stream
Size: 92899 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20220719/8963f755/attachment-0003.obj>