[m-dev.] Re: argument modes
bromage at cs.mu.OZ.AU
Tue Dec 15 19:45:31 AEDT 1998
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.
More information about the developers