[m-rev.] for review: prepare for checking insts' "for type_ctor/arity"

[Julien Fischer]

On Fri, 24 Dec 2021, Zoltan Somogyi wrote:

> Prepare for checking insts' "for type_ctor/arity".
> 
> This consists of two main parts.
> 
> The first part is creating a single point in time in a compiler invocation
> when this check can be done. This point in time has to be after typechecking,
> because (in the presence of type inference) this is the earliest point
> when type information is guaranteed to be available (in the absence of
> type errors, of course). The logical time is therefore the post-typecheck pass.
> The post-typecheck pass also does the closely related task of propagating type
> information into insts, but only the insts inside predicates' mode
> declarations. Before this diff, the task of propagating type information
> into the insts in the modes in lambda expressions was left to be done
> *during*, not *before*, mode checking. (I think the rationale was that
> you want to have propagated types into an inst in a procedure signature before
> you may see a call to that procedure. Mode checking may encounter a call
> to procedure of a predicate before processing that procedure, but due to
> mode reordering, it won't ever encounter a call to a lambda expression
> before processing the unification whose right hand side contains that
> lambda expression.) However, it is conceptually simpler if the post-typecheck
> pass takes over the propagation of types into insts even in lambda expressions,
> which is what this diff does.
> 
> The second part is cleaning up the code that does this propagation,
> to allow that cleanup to be reviewed separately from its modification
> to check for uses of user-defined insts for values of types other than
> the types that they are declared to be for.

That's fine.

Julien.