Re: Ann: delay pack
Jan Wielemaker <[email protected]>
| Newsgroups | gmane.comp.ai.prolog.swi |
|---|---|
| Message-ID | <[email protected]> |
On 08/12/2013 04:27 AM, Richard A. O'Keefe wrote:
>
> On 10/08/2013, at 6:22 AM, Ian Tegebo wrote:
>
>> Wow. I find it surprising that delay/1 didn't already exist. Could
>> someone more experienced comment as to previous approaches?
>
> There are two previous approaches.
There is also block/1 in SICStus (and in the SICStus emulation of
SWI-Prolog). It again is a directive that affects the definition of
the predicate.
> NU Prolog had 'when' declarations where you stated conditions under
> which a goal was to be *activated*, e.g.
>
> ?- append(A, Z, AZ) when A ; AZ.
> ?- succ(A, B, C) when ground(A), ground(B).
> ?- succ(A, B, C) when ground(B), ground(C).
> ?- succ(A, B, C) when ground(C), ground(A).
>
> There was a program that would automatically generate these for you
> for nicely behaved predicates.
>
> Some other Prologs have 'delay' declarations where you state
> conditions under which a goal is to be *suspended*, i.e., the
> opposite of the NU Prolog convention:
>
> :- delay succ(A, B, C) when var(A), var(B), var(C).
> :- delay append(A, Z, AZ) when var(A), var(AZ).
>
> I believe the "delay rule" convention is more powerful,
> but I always found the "activation rule" was easier for me
> to use, because it linked in with reasoning about termination.
>
> However expressed, the information belongs with the
> *definition* of a predicate, not with its uses.
[combined with "If there can be delay(...) wrappers in your code,
then there can be missing delay(...) wrappers." from your next
mail]
I'm not so sure. Yes, you can forget the delay(Goal) and write
Goal. That is a programmer error. It should be possible to find
that in most cases using mode analysis. The nice thing about
explicit inclusion of delay is that it makes you more aware of
the biggest risk: delaying over a cut changes the semantics.
So, if you use this you either should not use cuts or be very
careful with them. Without stronger analysis as in Mercury,
these extensions remain fragile in plain Prolog.
Cheers --- Jan