[m-rev.] for review: break up inst_util.m and mode_util.m

[Julien Fischer]

On Wed, 15 Dec 2021, Zoltan Somogyi wrote:

> For review by anyone. There are no changes in code;
> the only things to be reviewed are the new locations of code,
> the new comments at the tops of modules, and the new module
> descriptions in compiler_design.html.


> Break up inst_util.m and mode_util.m.
> 
> This step significantly improves module cohesion.

...

> diff --git a/compiler/inst_abstract_unify.m b/compiler/inst_abstract_unify.m
> index e69de29bb..ae2028d16 100644
> --- a/compiler/inst_abstract_unify.m
> +++ b/compiler/inst_abstract_unify.m
> @@ -0,0 +1,1493 @@
> +%---------------------------------------------------------------------------%
> +% vim: ft=mercury ts=4 sw=4 et
> +%---------------------------------------------------------------------------%
> +% Copyright (C) 1997-2012 The University of Melbourne.
> +% Copyright (C) 2015 The Mercury team.
> +% This file may only be copied under the terms of the GNU General
> +% Public License - see the file COPYING in the Mercury distribution.
> +%---------------------------------------------------------------------------%
> +%
> +% File: inst_abstract_unify.m.
> +% Author: fjh.
> +%
> +% This module does abstract unification of insts, which in effect
> +% does interpretation on  terms using insts as the abstraction mechanism.

There's an extra space after "on" there.

> +% A limitation is that we don't allow any unifications between functors
> +% and variables of mode `any'; the reason for that is that I have no
> +% idea what code we should generate for them. Currently `any' insts
> +% are only used for abstract types, so the type system should prevent
> +% any unification between functors and variables of mode `any'.
> +%
> +% Another limitation is that currently code generation assumes that insts
> +% `bound', `ground', and `any' are all represented the same way.
> +% That works fine for the CLP(R) interface but might not be ideal
> +% in the general case.
> +%

...


> diff --git a/compiler/notes/compiler_design.html b/compiler/notes/compiler_design.html
> index fd063bf41..fffaffc07 100644
> --- a/compiler/notes/compiler_design.html
> +++ b/compiler/notes/compiler_design.html
> @@ -1019,8 +1019,19 @@ and a whole bunch of service modules.
>      inst_match.m contains the code for examining insts
>      and checking whether they match.
>      <li>
> -    inst_util.m contains the code for creating new insts from old ones:
> -    unifying them, merging them and so on.
> +    inst_abstract_unify.m contains code for unifying insts.
> +    <li>
> +    inst_lookup.m contains code for looking up insts, possibly expanding
> +    references to user-defined insts in the process.
> +    <li>
> +    inst_merge.m contains code for merging insts. When the branches of
> +    an if-then-else or disjunction all bind a variable, this merging process
> +    figures out what the variable's inst should be when execution reaches
> +    the program point the branched control structure.

*after* the branched control structure.

> +    <li>
> +    inst_test.m contains various kinds of tests on insts.
> +    <li>
> +    inst_util.m contains code for creating new insts and modifying old insts.
>      <li>
>      mode_comparison.m module compares different modes of a predicate.
>      <li>
> @@ -1036,8 +1047,22 @@ and a whole bunch of service modules.
>      or a new mode for a user-defined predicate or function
>      whose set of modes is being inferred.
>      <li>
> -    mode_util.m contains miscellaneous useful predicates dealing with modes.
> -    Many of these are used by lots of later stages of the compiler.
> +    inst_mode_type_prop.m propagates type information into insts and modes.
> +    <li>
> +    recompute_instmap_deltas.m does what its name says: it recomputes
> +    the instmap deltas of the component goals of a procedure body.
> +    This needs to be done after virtually all changes to that body,
> +    so this module is used by many of the later stages of the compiler.
> +    <li>
> +    mode_test.m contains various kinds of tests on modes.
> +    <li>
> +    mode_top_functor.m computest the mode of the top functor of a term

s/computest/computes/

> +    from the mode of the whole term. This is of interest because it controls
> +    e.g. when a target language variable that holds the term becomes alive.
> +    <li>
> +    mode_util.m contains miscellaneous useful predicates dealing with modes,

The rest is fine.

Julien.