gooley@uicsl.UUCP (05/09/86)
Consider the following trivial predicate:
a([]).
a(_).
Given the query :-a([]). , C-Prolog finds one match and UNSW Prolog finds two.
Which is standard behavior? How do other implementations behave?
Mark Gooley, University of Illinois at Urbana-Champaign
{ihnp4 ; pur-ee ; seismo ; convex}!uiucdcs!uicsl!uicsg!gooley
uicsl!uicsg!gooley@a.cs.uiuc.educds@duke.UUCP (Craig D. Singer) (05/12/86)
In article <6500005@uicsl> gooley@uicsl.UUCP writes: > >Consider the following trivial predicate: > >a([]). >a(_). > >Given the query :-a([]). , C-Prolog finds one match and UNSW Prolog finds two. >Which is standard behavior? How do other implementations behave? I do not have the authority to say which is "standard" behavior, if by that you mean which is found more commonly in implementations. However, any book on "vanilla" Prolog will tell you that "_" matches to anything, including a null list, so I would indeed be annoyed by C-Prolog if it did not find two matches. Anybody disagree? -- Craig D. Singer, Dept. of Computer Science, Duke University Durham, NC 27706-2591. Phone (919) 684-5110 (ext.20) CSNET: cds@duke UUCP: ...!decvax!duke!cds ARPA: cds%duke@csnet-relay
cds@duke.UUCP (Craig D. Singer) (05/12/86)
In article <7233@duke.UUCP> cds@duke.UUCP (Craig D. Singer) writes: >In article <6500005@uicsl> gooley@uicsl.UUCP writes: >> >>Consider the following trivial predicate: >> >>a([]). >>a(_). >> >>Given the query :-a([]). , C-Prolog finds one match and UNSW Prolog finds two. >>Which is standard behavior? How do other implementations behave? > >I do not have the authority to say which is "standard" behavior, if by that >you mean which is found more commonly in implementations. However, any book >on "vanilla" Prolog will tell you that "_" matches to anything, including a >null list, so I would indeed be annoyed by C-Prolog if it did not find two >matches. Anybody disagree? Well, after I posted the above response I went ahead and checked out the version of C-Prolog which comes with 4.2/4.3 BSD and it DOES find two matches. The way to note this is to expand the predicate as follows: a([],2). a(_,3). Then ask the query a([],X). The response will be: X = 2 after which you can type a semicolon and hit return, which produces: X = 3 yes So C-Prolog (and, I would guess, any prolog) finds both matches. -- Craig D. Singer, Dept. of Computer Science, Duke University Durham, NC 27706-2591. Phone (919) 684-5110 (ext.20) CSNET: cds@duke UUCP: ...!decvax!duke!cds ARPA: cds%duke@csnet-relay
andrews@ubc-cs.UUCP (Jamie Andrews) (05/12/86)
In article <6500005@uicsl> gooley@uicsl.UUCP writes: >Consider the following trivial predicate: >a([]). >a(_). >Given the query :-a([]). , C-Prolog finds one match and UNSW Prolog finds two. >Which is standard behavior? How do other implementations behave? It depends what you mean by "one match". I should think all Prolog systems would just tell you that the query succeeds, since there are no free variables to get bindings for in the query. The standard reading of the predicate in FOL with identity would be a(X) <- X = [] \/ X = X. ...which, given the standard computation algorithm, should probably give two responses to the query :-a(X). ... namely, X=[] and X=X. --Jamie. ...!ihnp4!alberta!ubc-vision!ubc-cs!andrews
jhc@aber-cs.UUCP (James H. Cox) (05/13/86)
In article <6500005@uicsl> gooley@uicsl.UUCP writes: > >Consider the following trivial predicate: > >a([]). >a(_). > >Given the query :-a([]). , C-Prolog finds one match and UNSW Prolog finds two. >Which is standard behavior? How do other implementations behave? > Hmmmm, not exactly. Depends on what you mean by finding a match and how you apply the query. If you type a([]). to the C-prolog interpreter it comes back and says 'yes', ie the predicate can be satisfied. However, when you present such a query to the C-prolog top level interpreter it doesnt give you any opporunity to backtrack, you only get this opportunity if there are any variables given in your query, and you make use of this opportunity by typing ';' which invites the interpreter to backtrack. Below follows two dialogs with C prolog that indicate there are indeed two solutions to the query you mentioned.(Note that '?-' is the interpreter's prompt for you to type a query, and that ^ appears under user input) ?- a(X). -- initial query ^^^^^ X = [] ; -- first solution, ; typed so invoke ^ backtracking. X = _0 ; -- second solution.. ^ no -- prolog says no more solutions. ?- a([]), write(a), fail. -- need to phrase it like this to ^^^^^^^^^^^^^^^^^^^^^^ invoke backtracking since the interpreter will not give us the opportunity.. aa -- indicates 'write(a)' called twice. no -- no more solutions. ?- -- UUCP : { ENGLAND or WALES }!ukc!aber-cs!jhc JANET: jhc@uk.ac.aber.cs PHONE: +44 970 3111 x 3373 Post: University College of Wales, Penglais, Aberystwyth, UK, SY23 3BZ.
rggoebel@watdragon.UUCP (Randy Goebel LPAIG) (05/13/86)
> >Consider the following trivial predicate: > >a([]). > >a(_). > > > >Given the query :-a([]). , C-Prolog finds one match and UNSW Prolog finds two. > >Which is standard behavior? How do other implementations behave? _____________ > I do not have the authority to say which is "standard" behavior, if by that > you mean which is found more commonly in implementations. However, any book > on "vanilla" Prolog will tell you that "_" matches to anything, including a > null list, so I would indeed be annoyed by C-Prolog if it did not find two > matches. Anybody disagree? ------------- Hmmm. The reason for logic programming's existence is to dispense with guesses about what behaviour should be. The formulae assert that the individual constant named `[]' and everthing else (i.e., `_') is in the class named by the predicate `a'. If you believe that the anonymous variable is a universially quantified variable, then there are two resolution proofs of the query a([]). Implementors' treatment of `_' can produce non-standard behaviour; non-standard means not consistent with the logical interpretation.
bts@unc.UUCP (Bruce Smith) (05/14/86)
C-Prolog finds one solution at a time, UNSW looks for all solutions to a goal. C-Prolog (and many others) only give you a chance to ask for more solutions at the top level if there are free non-anonymous variables in your query. An easy way to show that C-Prolog was finding both solutions in the original program is ?- a([]), write(hello), nl, fail. Count the number of 'hello's. _____________________________________________________ Bruce T. Smith Dept. of Computer Science USENET: decvax!mcnc!unc!bts New West Hall (035-A) Others: bts.unc@CSNET-RELAY Chapel Hill, NC 27514
tfra@ur-tut.UUCP (Tom Frauenhofer) (05/14/86)
>>In article <7233@duke.UUCP> cds@duke.UUCP (Craig D. Singer) writes: >>In article <6500005@uicsl> gooley@uicsl.UUCP writes: >>> >>>Consider the following trivial predicate: >>> >>>a([]). >>>a(_). >>> >>>Given the query :-a([]). , C-Prolog finds one match and UNSW Prolog finds two. >>>Which is standard behavior? How do other implementations behave? >> >>I do not have the authority to say which is "standard" behavior, if by that >>you mean which is found more commonly in implementations. However, any book >>on "vanilla" Prolog will tell you that "_" matches to anything, including a >>null list, so I would indeed be annoyed by C-Prolog if it did not find two >>matches. Anybody disagree? >Well, after I posted the above response I went ahead and checked out the >version of C-Prolog which comes with 4.2/4.3 BSD and it DOES find two >matches. The way to note this is to expand the predicate as follows: >a([],2). >a(_,3). >Then ask the query a([],X). The response will be: >X = 2 >after which you can type a semicolon and hit return, which produces: >X = 3 >So C-Prolog (and, I would guess, any prolog) finds both matches. For whoever is collecting /interested in this information: I tried both of the above scenarios in Turbo Prolog and the PD version of A.D.A Prolog. The results: Turbo Prolog: First scenario: 1 match Second scenario: 2 matches A.D.A PDProlog: First scenario: 2 matches Second scenario: 2 matches -- Tom Frauenhofer ...!seismo!rochester!ur-tut!tfra
nabiel@erix.UUCP (Nabiel Elshiewy) (05/14/86)
In article <6500005@uicsl> Mark Gooley (gooley@uicsl.UUCP) writes: > >Consider the following trivial predicate: > >a([]). >a(_). > >Given the query :-a([]). , C-Prolog finds one match and UNSW Prolog finds two. >Which is standard behavior? How do other implementations behave? > Intuitively C-Prolog's one match is the expected standard behaviour. The two assertions describe a choice; it is either an empty list or something else which differs from an empty list. Aside: Also both Quintus Prolog and Mu-Prolog find one match.
gooley@uicsl.UUCP (05/15/86)
It seems that C-Prolog v1.3 (which I use) finds one match, but v1.5 finds two.
I suppose it was a bug that's now been fixed. Thanks to all who replied.
Mark Gooley, {ihnp4;per-ee;convex;seismo}!uiucdcs!uicsl!uicsg!gooleycdsm@doc.ic.ac.uk (Chris Moss) (05/22/86)
In article <980@watdragon.UUCP> rggoebel@watdragon.UUCP writes: >> >Consider the following trivial predicate: >> >a([]). >> >a(_). >> > >> >Given the query :-a([]). , C-Prolog finds one match and UNSW Prolog finds two. >> >Which is standard behavior? How do other implementations behave? >_____________ >> I do not have the authority to say which is "standard" behavior, if by that >> you mean which is found more commonly in implementations. Most of this discussion is not about how Prolog behaves, but how the top level query evaluator behaves. As a member of the Prolog standards committee but NOT speaking officially I should say that most environmental questions are being RULED OUT by the standards committee. Whether it will specify exactly what is the answer to a top level query is not yet sorted out. [To repeat what has been said already, the confusion is just about what response CProlog makes to a top-level query - if the query contains no variables it just answers "yes" and doesn't give the opportunity to look for another solution (all ways of solving it are equivalent so why bother). UNSW gives ALL solutions by default, even in this rather unnecessary case. If it was part of a larger problem, every Prolog I know would backtrack and find both, even though it was strictly equivalent] Chris Moss - cdsm@doc.ic.ac.uk or cdsm@icdoc.uucp
ludemann@ubc-cs.UUCP (Peter Ludemann) (05/24/86)
In article <980@watdragon.UUCP> rggoebel@watdragon.UUCP (Randy Goebel LPAIG) writes: >> >Consider the following trivial predicate: >> >a([]). >> >a(_). >> > >> >Given the query :-a([]). , C-Prolog finds one match and UNSW Prolog finds two. >> >Which is standard behavior? How do other implementations behave? >------------- >Hmmm. The reason for logic programming's existence is to dispense with >guesses about what behaviour should be. The formulae assert that the >individual constant named `[]' and everthing else (i.e., `_') is in the >class named by the predicate `a'. If you believe that the anonymous variable >is a universially quantified variable, then there are two resolution proofs >of the query a([]). > >Implementors' treatment of `_' can produce non-standard behaviour; non-standard >means not consistent with the logical interpretation. I have to disagree, Randy. The query merely asks whether or not there is a proof of "a([])". Not how many there are. Although by Prolog's execution order, there are only two ways of generating the answer, there are of course an _infinite_ number of logical proofs. There is no point in trying to list them all :-). Furthermore, if the goal "a([])" is within a predicate (for example, q(X) :- a([]), b(X).), then a smart implementation would notice that if "b(X)" fails, there is no need to re-try "a([])". Isn't that what all the work on intelligent backtracking has been about? Now, a general philosophical point. Prolog is certainly _not_ logic programming, although it is a large step in that direction. A true logic programming language would not have nor need "cut" ("!"), "var", "nonvar", etc. ("=..", "name", "is" and even "call" are legitimate because they can be considered as an infinite number of rules. "var" and "nonvar" can't be described that way). One of the advantages of logic programming is that it allows us to consider computations without knowing (precisely) the underlying execution strategy. Indeed, for "pure" programs, the execution strategy could change, yet the programs would still execute correctly. Let us strive to produce true logic programming languages which get over the minor failings of Prolog.
rggoebel@watdragon.UUCP (Randy Goebel LPAIG) (05/26/86)
> In article <980@watdragon.UUCP> rggoebel@watdragon.UUCP writes: >> >Consider the following trivial predicate: > >> >a([]). > >> >a(_). > >> > > >> >Given the query :-a([]). , C-Prolog finds one match and UNSW Prolog finds two. > >> >Which is standard behavior? How do other implementations behave? ---------------------------------- I did not! My response to whoever wrote that question was that if _ is a universally quantified variable, then the logic defines the correct answer; NOT the implementation. Isn't that what logic programming is for? 8-). Randy Goebel
rggoebel@watdragon.UUCP (Randy Goebel LPAIG) (05/26/86)
> >> >Consider the following trivial predicate: > >> >a([]). > >> >a(_). > >> > > >> >Given the query :-a([]). , C-Prolog finds one match and UNSW Prolog finds two. > >> >Which is standard behavior? How do other implementations behave? > >------------- > >Hmmm. The reason for logic programming's existence is to dispense with > >guesses about what behaviour should be. The formulae assert that the > >individual constant named `[]' and everthing else (i.e., `_') is in the > >class named by the predicate `a'. If you believe that the anonymous variable > >is a universially quantified variable, then there are two resolution proofs > >of the query a([]). > > > >Implementors' treatment of `_' can produce non-standard behaviour; non-standard > >means not consistent with the logical interpretation. > > I have to disagree, Randy. The query merely asks whether or not > there is a proof of "a([])". Not how many there are. -------------------------------------------------------------------- There is nothing in my reply that says anything about what an implementation should do with such proofs (count them, print them, ignore them, etc.). All it says is that there are two proofs. If you ask for all proofs, then there had better be two. 8-).
rggoebel@watdragon.UUCP (Randy Goebel LPAIG) (05/26/86)
> Now, a general philosophical point. Prolog is certainly _not_ logic > programming, although it is a large step in that direction. A true > logic programming language would not have nor need "cut" ("!"), > "var", "nonvar", etc. ("=..", "name", "is" and even "call" are > legitimate because they can be considered as an infinite number of > rules. "var" and "nonvar" can't be described that way). One of the > advantages of logic programming is that it allows us to consider > computations without knowing (precisely) the underlying execution > strategy. Indeed, for "pure" programs, the execution strategy could > change, yet the programs would still execute correctly. Let us > strive to produce true logic programming languages which get over the > minor failings of Prolog. Many claim that "logic programming" is an oxymoron. The logic of pure Prolog is well defined...that's all I said. I don't believe that cut, var, and nonvar cannot be described logically, just because they aren't in Prolog implementations.
mgv@euroies.UUCP ( Marco Valtorta) (05/28/86)
I find UNSW's behavior to be intuitively more correct, since it seems that the empty list "[]" should match the anonymous variable "_". This wouldn't be the first time that I find UNSW to act in a way that is closer to my "mental model" of Prolog. Maybe someone involved in a standardization effort could contribute something on this topic? [What contained above is my personal opinion.]:w -
lhe@sicsten.UUCP (Lars-Henrik Eriksson) (05/29/86)
In article <980@watdragon.UUCP> rggoebel@watdragon.UUCP writes: >... The formulae assert that the >individual constant named `[]' and everthing else (i.e., `_') is in the >class named by the predicate `a'. If you believe that the anonymous variable >is a universially quantified variable, then there are two resolution proofs >of the query a([]). There are indeed two resolution proofs of a([]), but as the two proofs produce indentical bindings (in this case, none), it is not obvious that you'd want two matches rather than one. The problem gets worse if you give the query a(X). Again you have two resolution proofs, but with different bindings. As one of the proofs subsumes the other, you could argue for a single match in this case as well (with the most general binding). I would prefer the single match in both cases.
lhe@sicsten.UUCP (Lars-Henrik Eriksson) (05/30/86)
In article <1021@watdragon.UUCP> rggoebel@watdragon.UUCP writes: >I don't believe that cut, var, and >nonvar cannot be described logically, just because they aren't in Prolog >implementations. The reason why cut, var and nonvar cannot be "described logically" is that they are non-logical (or meta-logical, if you wish) primitives, that is primitives used to control the search for proofs. The meaning of these primitives are dependent of the particular way an implementation looks for proofs. With a different implementation you could be forced to give a different meaning to cut, var and nonvar, or even find that they couldn't be given any meaning at all.
blenko@burdvax.UUCP (06/02/86)
In article <1163@sicsten.UUCP> lhe@sicsten.UUCP (Lars-Henrik Eriksson) writes: >In article <1021@watdragon.UUCP> rggoebel@watdragon.UUCP writes: >>I don't believe that cut, var, and nonvar cannot be described >>logically, just because they aren't in Prolog implementations. >The reason why cut, var and nonvar cannot be "described logically" is >that they are non-logical (or meta-logical, if you wish) primitives, >that is primitives used to control the search for proofs. >The meaning of these primitives are dependent of the particular way an >implementation looks for proofs. With a different implementation you >could be forced to give a different meaning to cut, var and nonvar, or >even find that they couldn't be given any meaning at all. I disagree with the latter comment. If call() and negation-by-failure are provided, I claim that you can define if-then-else() (with your favorite syntax, say P->Q;R), and that if-then-else() is more expressive than cut(). In particular, you need a scoping construct for cut() to make it as expressive as if-then-else(). It is a short exercise to show that that var() and nonvar() can be expressed using call() and cut() (or if-then-else()). So the discussion reduces to establishing the logical or non-logical character of call() and negation-by-failure(). I will speculate that the meaning of call() can be captured by a suitable application of first-order logic, due to its definition in terms of constructive proofs (I have something along the lines of Perlis' AIJ (1985) article in mind here). I am side-stepping the problem of incompleteness of logic-programming interpreters w.r.t resolution. Tom
debray@sbcs.UUCP (Saumya Debray) (06/02/86)
> In article <1021@watdragon.UUCP> rggoebel@watdragon.UUCP writes: > >I don't believe that cut, var, and > >nonvar cannot be described logically, just because they aren't in Prolog > >implementations. > > The reason why cut, var and nonvar cannot be "described logically" is that > they are non-logical (or meta-logical, if you wish) primitives, that is > primitives used to control the search for proofs. Perhaps you mean "... cannot be described logically using first order predicate calculus". > The meaning of these primitives are dependent of the particular way an > implementation looks for proofs. With a different implementation you > could be forced to give a different meaning to cut, var and nonvar, or > even find that they couldn't be given any meaning at all. If the constructs are in any way "understandable", you ought to be able to find mathematical models for them. In the case of "cut", "var" etc. there's a good chance these won't look like the Herbrand models we Prolog hackers are accustomed to, of course, but that's rather different from saying that they couldn't be given any meaning at all. There has, in fact, been some work on giving the semantics of Prolog (i.e. textual order on literals and clauses + Cut) using classical denotational semantics, in terms of continuous functions over CPOs. References are: - Jones & Mycroft, "Stepwise Development of Denotational and Operational Semantics for Prolog", Proc. 1st ISLP, Atlantic City, Feb 1984. - Debray & Mishra, "Denotational and Operational Semantics for Prolog", Proc. Conf. on Formal Description of Programming Concepts, Lyngby, Denmark, Aug 1986 (to appear). -- Saumya Debray SUNY at Stony Brook uucp: {allegra, philabs, ogcvax} !sbcs!debray arpa: debray%suny-sb.csnet@csnet-relay.arpa CSNet: debray@sbcs.csnet
rggoebel@watdragon.UUCP (Randy Goebel LPAIG) (06/02/86)
> The reason why cut, var and nonvar cannot be "described logically" is that > they are non-logical (or meta-logical, if you wish) primitives, that is > primitives used to control the search for proofs. > > The meaning of these primitives are dependent of the particular way an > implementation looks for proofs. With a different implementation you > could be forced to give a different meaning to cut, var and nonvar, or > even find that they couldn't be given any meaning at all. --------------- The standard implementation of Prolog provides a standard meaning for the primitives described as non-logical. These primitives have an interpretation in a semantic domain that includes Prolog proofs (and partial proofs) as objects. Such a formalization, if produced, would provide a standard specification for ``non-logical'' primitives of ordinary Prolog implementations. I don't believe that anyone really believes that any Prolog primitive is inherently unformalizable?
reddy@uiucdcs.CS.UIUC.EDU (06/03/86)
To rggoebel@watdragon: You can try explaining cut, var and nonvar logically. If you do it successfully, you could become a star of the logic programming community.
rggoebel@watdragon.UUCP (Randy Goebel LPAIG) (06/04/86)
Reddy@utah writes: > You can try explaining cut, var and nonvar logically. If you do it > successfully, you could become a star of the logic programming community. -------
reddy@uiucdcs.CS.UIUC.EDU (06/08/86)
/* Written 6:10 pm Jun 1, 1986 by blenko@burdvax.UUCP in uiucdcs:net.lang.prolog */ So the discussion reduces to establishing the logical or non-logical character of call() and negation-by-failure(). I will speculate that the meaning of call() can be captured by a suitable application of first-order logic, due to its definition in terms of constructive proofs (I have something along the lines of Perlis' AIJ (1985) article in mind here). I am side-stepping the problem of incompleteness of logic-programming interpreters w.r.t resolution. Tom /* End of text from uiucdcs:net.lang.prolog */ We should be careful about what we mean by negation-by-failure. If it is applied to ground atoms, it is certainly logical (see for example Lloyd's book). But when it is applied to non-ground atoms, it messes up with the quantification of variables in the atoms. Hence, it should not be surprising that it is possible to define cut etc using it.
gilbert@aimmi.UUCP (Gilbert Cockton) (06/09/86)
In article <29700028@uiucdcs> reddy@uiucdcs.UUCP writes: > >To rggoebel@watdragon: > >You can try explaining cut, var and nonvar logically. If you do it >successfully, you could become a star of the logic programming community. In all humility, and with a strong chance of getting it all wrong here I go: var(X) = All t in Term: can_unify(t,X) where can_unify is true if a most general unifier can be found for both its arguments. nonvar(X) = Exists t in Term: NOT(can_unify(t,X)) Dirty structures like lists with uninstantiated tails (as in the unit time queue trick) are nonvar under these definitions. I've had minimal training in Logic, so I don't know if the set of all Terms is an ok construct. Seems ok to me. This leaves cut, which is definitely meta-logical.
lhe@sicsten.UUCP (06/13/86)
In article <127@sbcs.UUCP> debray@sbcs.UUCP writes: >... >Perhaps you mean "... cannot be described logically using first order >predicate calculus". I did. The posting I responded to talked about "cut" etc. as being "described logically". I understood this as meaning "defined in pure Prolog" (or in first order predicate calculus), whis is not possible. Certainly you can define things like "var" using other nonlogical constructs. >If the constructs are in any way "understandable", you ought to be able to >find mathematical models for them. In the case of "cut", "var" etc. there's >a good chance these won't look like the Herbrand models we Prolog hackers are >accustomed to, of course, but that's rather different from saying that they >couldn't be given any meaning at all. >... I agree completely.
lhe@sicsten.UUCP (Lars-Henrik Eriksson) (06/14/86)
In article <768@aimmi.UUCP> gilbert@aimmi.UUCP (Gilbert Cockton) writes: >... >var(X) = All t in Term: can_unify(t,X) > >where can_unify is true if a most general unifier can be found for both >its arguments. > >nonvar(X) = Exists t in Term: NOT(can_unify(t,X)) > >Dirty structures like lists with uninstantiated tails (as in the unit >time queue trick) are nonvar under these definitions. > >I've had minimal training in Logic, so I don't know if the set of all >Terms is an ok construct. Seems ok to me. >... There is nothing wrong with your definitions, except that you now have to define the predicate "can_unify"... This can't be done within predicate logic, either. To defend a claim that something can be defined, you have to define it completely, and not depend on new predicates with dubious definability.
alan@cheops.OZ (Alan Tonisson) (06/19/86)
> In article <29700028@uiucdcs> reddy@uiucdcs.UUCP writes: > > > >To rggoebel@watdragon: > > > >You can try explaining cut, var and nonvar logically. If you do it > >successfully, you could become a star of the logic programming community. > > In all humility, and with a strong chance of getting it all wrong here I > go: > > var(X) = All t in Term: can_unify(t,X) > > where can_unify is true if a most general unifier can be found for both > its arguments. > > nonvar(X) = Exists t in Term: NOT(can_unify(t,X)) > > Dirty structures like lists with uninstantiated tails (as in the unit > time queue trick) are nonvar under these definitions. > > I've had minimal training in Logic, so I don't know if the set of all > Terms is an ok construct. Seems ok to me. > > This leaves cut, which is definitely meta-logical. It is not possible to talk about the SET of all terms within first order predicate calculus, but it is possible to state that some property holds for all things (i.e. it is true of all terms) e.g. forall X: p(X) says that p holds for all things and hence p(t) is true for any term t. The real problem with the above definitions is that one cannot define can_unify within first order predicate calculus. can_unify is just as nasty a beast as var and nonvar are. Alan Tonisson.
avg@diablo.UUCP (06/25/86)
| In article <29700028@uiucdcs> reddy@uiucdcs.UUCP writes: | | To rggoebel@watdragon: | | You can try explaining cut, var and nonvar logically. If you do it | | successfully, you could become a star of the logic programming community. | | In all humility, and with a strong chance of getting it all wrong here I | go: | .... Then alan@cheops.OZ (Alan Tonisson) shoots down the attempt. A simple way to convince yourself that these are non-logical is to remember that AND and OR are commutative and associative. Thus a clause has the same logical meaning under all permutations of its literals. But clearly, clauses with cut, var, and nonvar do not have this property, in general -- the order of subgoals DOES matter. QED