[m-rev.] for review: associate a type with an inst

[Julien Fischer]

On Thu, 16 Dec 2021, Zoltan Somogyi wrote:

> Associate a type with an inst.
> 
> Many predicates working on the inst of a variable (or part of the value of
> a variable) need to know the type of (that part of) the variable, but
> in some contexts, the type is not available at compile time. (One instance
> is the type of an existentially typed argument.) Because of this, the
> compiler used to pass a maybe(mer_type) with each mer_inst.
> 
> Act on an old XXX to change this to pass a mer_type with each mer_inst,
> with the mer_type being a type variable if the type is not known statically.
> This is conceptually cleaner, and should also be faster, due to avoiding
> yes() wrappers in the usualy case where the type *is* available.

s/usualy/usual/

...

> diff --git a/compiler/inst_util.m b/compiler/inst_util.m
> index d3a09ba49..05bb73a36 100644
> --- a/compiler/inst_util.m
> +++ b/compiler/inst_util.m

...

> @@ -73,14 +72,30 @@
>      % XXX This predicate returns the types of the arguments, but
>      % loses any ho_inst_info for the arguments.
>      %
> -:- pred maybe_get_cons_id_arg_types(module_info::in, maybe(mer_type)::in,
> -    cons_id::in, arity::in, list(maybe(mer_type))::out) is det.
> +:- pred get_cons_id_arg_types(module_info::in, mer_type::in,
> +    cons_id::in, arity::in, list(mer_type)::out) is det.
>
>      % XXX This predicate returns the types of the arguments, but
>      % loses any ho_inst_info for the arguments.
>      %
> -:- pred maybe_get_higher_order_arg_types(maybe(mer_type)::in, arity::in,
> -    list(maybe(mer_type))::out) is det.
> +:- pred get_higher_order_arg_types(mer_type::in, arity::in,
> +    list(mer_type)::out) is det.
> +
> +    % Return a type that represents the *absence* of type information.
> +    % This type is a type variable. Since the predicates and functions
> +    % working on insts and modes use type information *only* to look up
> +    % the constructors of a type, this conveys exactly the right info.
> +    %
> +    % Note that we always return the *same* type variable. Besides matching
> +    % the semantics expected of functions, it also means our callers will not
> +    % construct non-canonical inst_match_inputs structures. The fact that
> +    % we return the same type variable as the "types" of e.g. different
> +    % existentially typed arguments of a data constructor is not a problem,
> +    % even though those argument may contain values of different types at

s/argument/arguments/

The rest is fine.

Julien.