[m-users.] delay declarations in Mercury

[Zoltan Somogyi]

On Fri, 23 Jan 2015 09:34:01 +0100, Matthias Guedemann <matthias.guedemann at googlemail.com> wrote:
> If yes, is it in general possible to express the delay declarations in
> Mercury using mode declarations?

Delay declarations are used in Prolog systems to schedule goals
at runtime. Mercury's mode declarations are used to schedule goals
at compile time. The two have similar aims, but are fundamentally
different.

Systems using delay declarations necessarily have overheads at runtime
for checking, rechecking and re-rechecking whether delayed goals may
now run again. Scheduling at compile time completely avoids these overheads.
By giving the compiler guaranteed information about what variables are bound
when, it also allows the generation of significantly better code.

On the other hand, if you have a test predicate that has several input arguments
but can decide that it cannot succeed given the values of only some of them,
then waking up calls to that test predicate when these some arguments are
known, *without* waiting for the other input arguments to become known,
may allow the early pruning of a branch of computation. Since the cost of
such branches is unbounded, this may be an arbitrarily large speedup.
You can do this as a user level programmer with delay declarations
in dynamically scheduled Prolog systems; to do the same in a statically scheduled
system like Mercury, you need a program transformation inside the Mercury compiler.
The Mercury compiler does have such a transformation, but it won't handle every
situation you may want it to.

The reason why I don't think this is a problem is that the kinds of problems
that can be significantly improved by using delay declarations can be improved
even further, by *huge* margins, by the use of specialized constraint solving
systems, which have *far* more freedom to rearrange the order of computation,
and make full use of it. I consider delay declarations (and their relatives, such
as when declarations in Nu-Prolog) as being not really suited to either of the
two main uses cases I care about. One, they are not as good as Mercury's
mode system for general application programming, since they are slower
and cannot give useful guarantees; two, they are nowhere as good as
constraint solving systems for constraint problems.

Zoltan.