[m-dev.] EDCGs

[Peter Nicholas MALKIN]

Hi,

Another possible addition (yes another) to the EDCG syntax is another form
besides passed and changed. If a predicate has the form `passed' for a hidden
variable, that variable can be thought of as being used (and not changed) within
the predicate. If a predicate has the `changed' for a hidden variable, that
variable can be thought of as being used and changed. However what about the
case where the variable is not used and just changed. For instance, a predicate
initialises or resets a hidden variable. In these cases the original value of
the hidden variable is not needed, hence ideally only one argument needs to be
passed to the predicate. For want of a better word I will call the new form
`produced'.

Everything that could be done through using `produced' can be done through
`changed' where the first argument is ignored. This is annoying, but nothing too
problematic though. `produced' however does have the added advantage of
providing the user more flexibility with specifying modes of hidden arguments.

Unfortuneately by adopting a new form which passes one argument the proposed
syntax would need to change, besides just adding a new form.

The problem occurs with EDCG goals and predicate calls which use the number of
arguments supplied to a hidden variable to decide what form it is called in. Two
arguments means changed and one means passed. However with produced which only
receives one this is not possible.

An EDCG goal may thus become:

(edcg(changed(hidden1, Initial1, Final1), passed(hidden2, Initial1),
	produced(hidden3, Final2)) -->>
	...
)

where hidden1, hidden2 and hidden3 are hidden variables and Initial1, Initial2,
Final1 and Final2 are all terms.

This could be slightly condensed to:

([changed(hidden1, Initial1, Final1), passed(hidden2, Initial2),
	produced(hidden3, Final2)] -->>
	...
)

In summary, `produced' would be a nicety but not a necessity.

Comments please?

Peter

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------