Article View: comp.lang.prolog
Article #460Re: Dynamic Properties
From: Chris Moss
Date: Wed, 08 Nov 1989 17:46
Date: Wed, 08 Nov 1989 17:46
59 lines
3218 bytes
3218 bytes
In article <5500@ubc-cs.UUCP> kean@faculty.cs.ubc.ca (Alex Kean) writes:
> I proceed the experiment by using the meta-interpreter
>defined by Sterling and Shapiro in their book (The Art of Prolog):
>
> 1) solve(true).
> 2) solve((A,B)) :- solve(A), solve(B).
> 3) solve(X) :- clause(X,Y), solve(Y).
>
>I guess I was surprise when the above program would not run in Quintus
>prolog upon any backtracking. After understanding the debugging
>behavior, I realized that upon backtracking, the term (A,B) in clause
>(2) is unifiable with X in clause (3) and when the call of
>
> clause((A,B),Y) in clause(3),
>
>Quintus prolog reply with "attempting to use clause/2 on static predicate.."
> 2) Is there an obvious solution to my problem that I am missing ?
In Quintus what you need is:
1) solve(true).
2) solve((A,B)) :- solve(A), solve(B).
3) solve(X) :- \+(X=true;X=(_,_)), clause(X,Y), solve(Y).
Yes, it's a bit odd isn't it, and though Richard has argued against the
Sterling/Shapiro version I don't think he has a very good case.
Instead of the negated bit above he prefers the 3rd clause as:
solve(X) :- predicate_property(X, interpreted),
clause(X,Y), solve(Y).
and you then have to provide the appropriate definition, which by now should
be child's play!
There's another hidden problem: the obvious way to write my 3rd clause would
be X\=true, X\=(_,_) but Quintus, unlike Clocksin & Mellish, C-Prolog
etc. does NOT provide \=. I've never understood why.
>
> 3) As I am not a Prolog expert, I am speaking from a user point of
> view. I use high level programming languages because I want fast
> prototyping capability to test out my theorems and lemma.
> In this situation, I find myself *not* testing my result but rather
> combating with different systems specific capabilities and drawbacks.
> Is my experience unwarranted ?
This of course is precisely the argument in fovour of standardization.
The problem with that was that everyone wanted to standardize on the way
THEY did it. The set of comparison operators is a good example of the
trouble this causes. In sequential Prolog one really needs 3 sets: arithmetic,
term ordering and unification (equality and inequality). So that comes
to a fair packet (at least 14). If you support a coroutining implementation
of Prolog then you argue that \= should be delayed until it sufficiently
ground. If you support constraints, then you want to allow arithmetic
inequalities to be partially instantiated. Some people then argue that
having @< for term less than and \== for term inequal is inconsistent and hard
to remember. And so on.
Now read on on the discussion of standards...
Chris Moss.
Technical Details
Message-ID:
<1350@gould.doc.ic.ac.uk>Path:
arc1-ca.pugleaf.net!utzoo!attcan!uunet!mcsun!ukc!icdoc!sappho!cdsmReferences:
<5500@ubc-cs.UUCP>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!mcsun!ukc!icdoc!sappho!cdsm From: cdsm@sappho.doc.ic.ac.uk (Chris Moss) Newsgroups: comp.lang.prolog Subject: Re: Dynamic Properties Message-ID: <1350@gould.doc.ic.ac.uk> Date: 8 Nov 89 17:46:30 GMT References: <5500@ubc-cs.UUCP> Sender: news@doc.ic.ac.uk Reply-To: cdsm@doc.ic.ac.uk (Chris Moss) Distribution: comp.lang.prolog Organization: Logic Group, Dept. of Computing, Imperial College, London, UK. Lines: 59