[m-dev.] Re: argument modes

[Andrew Bromage]

G'day all.

Simon Taylor wrote:

> That's fine, but as far as I can see, the inst_table in the argument modes
> field of a proc_info is not guaranteed to hold all of the inst_keys occurring
> in the argument modes.

If they the inst_keys are declared, it is guaranteed.

> After mode checking the goal for a procedure the new
> final insts are placed in the argument modes,

They shouldn't be.  The argument modes are what the user declares.

As for compiler-generated procs, that's a different issue.  The case of
unify_procs is easy, since the arguments modes are just the unify_modes
of the complicated unification (that's how I envisage the "interface" of
a complicated_unify).  As for other compiler-introduced procs (e.g.
ref_in modes), I haven't put much thought to it as I haven't written any
code which produces said procs.

It seems to me that before the compiler produces a proc (for whatever
reason), it will already have a pretty good idea of what the mode should
be.  For example, in "fold" operations (e.g. dnf.m), it would normally
be the instmap_delta of the folded goal.

I'm not sure if these thoughts generalise to any compiler-generated proc.

Correspondence will be entered into.

Cheers,
Andrew Bromage