for review: EDCGs and insts

[Peter Nicholas MALKIN]

On Tue, 3 Mar 1998, Peter Schachte wrote:

> I can see that `consumed' with mode out would make sense, but I would
> expect `passed' with mode out would be a problem when the next goal that
> used that hidden argument was reached.
>
> The modes for these uses (we need a word for the set of possibilities
> {changed, passed, consumed, produced}; for now I'll call them `uses')
> have to be compatible.  The final inst of `produced' and `changed' has
> to be compatible with the initial inst of `changed', `passed', and
> `consumed', doesn't it?  As far as I can see, you really only need to
> specify three insts: the initial inst for `produced', the final inst
> for `consumed', and the common inst for everything else.  Call them
> `first', `middle', and `last'.  Then the modes for the introduced
> arguments in the generated code would be
>
>       produced:  first->middle
>       passed:    middle->middle
>       changed:   middle->middle, free->middle
>       consumed:  middle->last

Hidden argument forms specify the scope in which the variable associated
with the hidden argument can be used, and the instantiation of the
variable at any point is unrelated. Hidden argument forms basically 
declare WHEN a hidden argument can be used and NOT HOW a hidden argument 
can be used. Hence the forms do not *have* to be compatible, and if the 
instantiations do not match for two forms in a particular order then the 
programmer cannot use the forms in that order. Although, in the majority  
of cases the instantiations of the variables will be as you have
mentioned.

I have noticed when writing test code in EDCGs that if you restrict
the modes of the different forms of the hidden arguments to be as you
have listed above then you restrict where and how the hidden arguments can
be used. 

Perhaps what is required is that hidden arguments can have multiple
different modes declared for a particular form (at present only one mode
declaration is allowed).

>> Passed indicates that the predicate call recieves a hidden argument and
>> passes on the same hidden argument, to the next goal.
>  
>Do you mean by this that the call winds up with two extra arguments?
>I would expect that one would be enough for `passed'.

No, the fact that the hidden argument is passed on refers only to the
scope of the hidden argument.

> I also think first will usually be free, middle will usually be
> ground, and last will usually be dead(whatever middle is), so I think
> it makes sense to have these as defaults. Why make users write, and
> maintainers read, lots of text that has little information other than
> "yup, it's the usual"?

Mode declarations only need to be declared once per form of a hidden
argument and this in itself usually results in a reduction in code. I do
not like the idea of inferring modes for the hidden arguments as this is
against the mercury ideal of comparing what is inferred with declared to
check that what the programmer wrote was what was intended.

The syntax is meant to be simple and unfortunately it is also rather ad
hoc. It is not supposed to be used often or in a complex manner, but
instead used in situations where arguments are passed on with little else
done to them.

Peter.