[m-rev.] for post-commit review: document an issue with tuple_cons cons_ids

[Peter Wang]

On Fri, 26 Feb 2021 20:40:07 +1100 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> Add an XXX about tuple_cons cons_ids.
> 
> compiler/prog_data.m:
>     As above.

> diff --git a/compiler/prog_data.m b/compiler/prog_data.m
> index c4ebe1f17..477ea72f0 100644
> --- a/compiler/prog_data.m
> +++ b/compiler/prog_data.m
> @@ -114,6 +114,22 @@
>              % resolve_unify_functor.m has been run as part of the
>              % post-typecheck pass. Until then, they are represented as
>              % cons(unqualified("{}"), ...).
> +            %
> +            % XXX Unfortunately, the above is not quite true. The utility
> +            % predicate type_constructors in type_util.m return the cons_ids
> +            % of a type, but it does not know what the current pass is.
> +            % When called on a tuple type, it can therefore either *always*
> +            % return cons(unqualified("{}"), ...), or it can *always* return
> +            % tuple_cons(Arity). It does the former, which means that any code
> +            % that deals with its output, directly or indirectly, which
> +            % certainly includes code that uses inst_match.m and probably
> +            % includes other modules as well, has to be prepared for this.
> +            %
> +            % XXX I (zs) also strongly suspect that while post-typecheck.m.
> +            % may replace occurrences of cons(unqualified("{}"), ...) in a
> +            % procedure's body goal with tuple_cons(Arity), it won't replace
> +            % similar occurrences in bound_insts in those procedures' mode
> +            % declarations.

Do you know the reason for using tuple_cons(Arity) instead of
cons(unqualified("{}"), Arity, ...)?

Peter