Re: pilog: unification in variables that are clauses
Hi Doug, > We have golog in pilog. Er, I think :-) If not we're pretty dang close. Cool! :) > With miniPicoLisp at 100 to 150k (depending on platform, build > options, etc.) and with pilog + golog loaded, it has to be the smallest > footprint golog (with a respectable prolog and lisp under the hood), > around. Might be right for embedded systems, I'm thinking. If space is an issue, you might consider decreasing CELLS in "mini/src/pico.h". It determines the heap allocation size. It is currently (1024*1024/sizeof(cell)) = 1 MByte. At startup, the first heap is allocated, so the minimum runtime size is 1 MByte. In the very first PicoLisp versions on the Mac it was only 32 kBytes, because the memory manager in the Mac toolbox didn't allow for larger sizes. So it doesn't harm to decrease CELLS. The only point where it matters is the 'heap' function, as it counts the number of heaps and implicitly multiplies it by 1 MB. This function must be adjusted then. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pilog: unification in variables that are clauses
Thanks Alex!!! We have golog in pilog. Er, I think :-) If not we're pretty dang close. Still trying to get the simple elevator example going from "Knowledge in Action" as a test. http://www.cs.toronto.edu/cogrobo/kia/simpleElevator http://books.google.com/books?q=%22proc%28goFloor%22 etc. After golog, maybe indigolog ? With miniPicoLisp at 100 to 150k (depending on platform, build options, etc.) and with pilog + golog loaded, it has to be the smallest footprint golog (with a respectable prolog and lisp under the hood), around. Might be right for embedded systems, I'm thinking. Cheers, Doug --- On Thu, 6/30/11, Alexander Burger wrote: > From: Alexander Burger > Subject: Re: pilog: unification in variables that are clauses > To: picolisp@software-lab.de > Date: Thursday, June 30, 2011, 11:55 PM > Hi Doug, > > the following works: > > (be a (3)) > > (be foo @C > (2 -> @C) ) > > > : (? (foo (a @Z))) > @Z=3 > > -> NIL > > I spied what 'call/1' is doing ;-) That number magic with > '2' is a bit > tricky, I'm never sure what level to pick. Basically it > tells the > interpreter with which level it should unify (here, the > level outside of > 'foo'). > > > Actually, you could also use > > (be foo (@C) > (2 cons (-> @C)) ) > > but this needs additional consing for the expression to > match, so I > would avoid it. It depends on what else is done with '@C'. > > Cheers, > - Alex > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pilog: unification in variables that are clauses
Hi Doug, the following works: (be a (3)) (be foo @C (2 -> @C) ) : (? (foo (a @Z))) @Z=3 -> NIL I spied what 'call/1' is doing ;-) That number magic with '2' is a bit tricky, I'm never sure what level to pick. Basically it tells the interpreter with which level it should unify (here, the level outside of 'foo'). Actually, you could also use (be foo (@C) (2 cons (-> @C)) ) but this needs additional consing for the expression to match, so I would avoid it. It depends on what else is done with '@C'. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pilog: unification in variables that are clauses
The "solve" way seems to some closest to doing it. ~/lisp/miniPicoLisp $ cat t.l (be a (3)) (be foo (@C) # (@C -> @C) # (call @C) (@ print (solve (list (-> @C ) $ ./pil t.l : (? a foo (foo (a @Z))) 1 (foo (a @Z)) (((@Z . 3)))-> T So I can see that it is correctly solving for @Z this way. But it doesn't take that binding (@Z = 3) back into the foo rule. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pilog: unification in variables that are clauses
Here's the issue boiled down to a simpler test case :-) First, swi-prolog: # cat t.pl a(3). foo(N) :- N. bar(a(X)) :- a(X). # swipl -f t.pl % /root/prolog/t.pl compiled 0.00 sec, 2,800 bytes ... ?- trace. true. [trace] ?- bar(a(Z)). Call: (6) bar(a(_G386)) ? creep Call: (7) a(_G386) ? creep Exit: (7) a(3) ? creep Exit: (6) bar(a(3)) ? creep Z = 3. [trace] ?- foo(a(Z)). Call: (6) foo(a(_G386)) ? creep Call: (7) a(_G386) ? creep Exit: (7) a(3) ? creep Exit: (6) foo(a(3)) ? creep Z = 3. In both cases, Z is correctly bound to 3. (The foo rule is the one we are interested in.) $ cat t.l (be a (3)) (be foo (@C) (@C -> @C)) (be bar ((a @N)) (a @N)) ~/lisp/miniPicoLisp $ ./pil t.l : (? a bar (bar (a @X))) 1 (bar (a @N)) 1 (a 3) @X=3 -> NIL That is correct: @X=3 ... however : : (? a foo (foo (a @X))) 1 (foo (a @X)) @X=NIL -> NIL : But they should be the same, as @X = 3 is a (is the) solution. Moreover, in foo (a @X) is never even tried to be proven. So I think this test case demonstrates the issue. > I still don't understand why this test of @A and/or @F for > being non-NIL is necessary at all. This looks unusual to me. holds(A,S) :- restoreSitArg(A,S,F), F ; \+ restoreSitArg(A,S,F), isAtom(A), A. Me too. At first, I also thought they simply were testing for non-NIL there. But the intent of the 'naked' F and A clauses there seems to be this: If the data bound to F (or A) is itself a clause, then that clause gets proved and variables in it get unified/bound. So after the first restoreSitArg(A,S,F), F starts out as partially bound to a clause like on(N,s0) - which itself has an unbound variable, N. After F is proven, N is bound to 3 (because on(3,s0) is asserted elsewhere, and so N = 3 is a solution). A bit tricky, with variables bound to clauses which, in turn, have in them other unbound variables that may get bound. Using call/1 there (not sure if this is the way I should use it) gives similar results, where (a @X) is not attempted to be proven. $ cat t.l (be a (3)) (be foo (@C) # (@C -> @C)) (call @C)) ~/lisp/miniPicoLisp $ ./pil t.l : (? a foo call (foo (a @X))) 1 (foo (a @X)) 1 (call (a @X)) -> NIL : Cheers, Doug -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pilog: unification in variables that are clauses
Hi Doug, > (be holds (@A @S) >(or > ((restoreSitArg @A @S @F) (@ -> @F)) > ((not (restoreSitArg @A @S @F)) (isAtom @A) (@ -> @A)) ) ) > > gives me the same results as using the (@ solve (list (-> @F))) > clause. Neither that nor (@ -> @F) seem to unify variables in @F (which > is bound to a clause) (@ -> @F) just matches locally, without binding variables. What happens if you use (@F -> @F) or (@A -> @A)? This will unify the variable with its Lisp value. Or did I understand right that @F and/or @A contain another Pilog clause? Then: Can't you use (call @A), as I wrote in my last mail? I still don't understand why this test of @A and/or @F for being non-NIL is necessary at all. This looks unusual to me. On the other hand, I'm a really poor Prolog programmer ... Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pilog: unification in variables that are clauses
Hi Alex, Thanks for your help! holds(A,S) :- restoreSitArg(A,S,F), F ; \+ restoreSitArg(A,S,F), isAtom(A), A. What I really want is this: (be holds (@A @S) (or ((restoreSitArg @A @S @F) @F) ((not (restoreSitArg @A @S @F)) (isAtom @A) @A) ) ) But the above (with a @F or @A for a clause) doesn't work. :-( This - (be holds (@A @S) (or ((restoreSitArg @A @S @F) (@ -> @F)) ((not (restoreSitArg @A @S @F)) (isAtom @A) (@ -> @A)) ) ) gives me the same results as using the (@ solve (list (-> @F))) clause. Neither that nor (@ -> @F) seem to unify variables in @F (which is bound to a clause) : (solve '((holds (On @N) s0))) -> (T) Solves, but it also should tell me @N is bound to 3 Cheers, Doug --- On Thu, 6/30/11, Alexander Burger wrote: > From: Alexander Burger > Subject: Re: pilog: unification in variables that are clauses > To: picolisp@software-lab.de > Date: Thursday, June 30, 2011, 12:27 AM > On Thu, Jun 30, 2011 at 09:20:43AM > +0200, Alexander Burger wrote: > > At least, a simple (@ . @A) should work. Doesn't it? > > Wait ... probably not a good idea. > > But this should work: (@ -> @A) > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pilog: unification in variables that are clauses
On Thu, Jun 30, 2011 at 09:20:43AM +0200, Alexander Burger wrote: > At least, a simple (@ . @A) should work. Doesn't it? Wait ... probably not a good idea. But this should work: (@ -> @A) -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pilog: unification in variables that are clauses
Hi Doug, > > So this should be written as > > > >(be holds (@A @S) > > (or > > ((restoreSitArg @A @S @F) (@ solve (list (-> @F > > ((not (restoreSitArg @A @S @F)) (isAtom @A) (@ solve (list (-> @A ) ) I didn't test it, but I think the construct using 'solve' is more complicated than necessary. At least, a simple (@ . @A) should work. Doesn't it? In any case, I'm wondering why this problems exists. Usually, variables are not unified with NIL during normal processing. How comes that this happens with '@A'? > When I try to do this as (@ (solve (list (-> @F in pilog, taking Note that the '(' before 'solve' is not correct. In the example above you have it right, though. > I wonder what I should do in this case, where a variable can be bound > to a clause like that and the variables in that clause need to be bound, > too? I would believe that this case is quite common. I must confess that I don't remember the details very well, but some system predicates in "lib/pilog.l" do similar things. For example the 'not', 'call' and 'or' predicates evaluate argument clauses, including unification etc. The syntactic element in Pilog for that is that the clause starts with a number (as opposed to a symbol for "normal" clauses, and a @Variable for Lisp expressions). Then that number specifies the nth surrounding environment where that clause is to be unified in. Perhaps it is even enough in your case, if you use 'call'? Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
pilog: unification in variables that are clauses
--- On Wed, 6/29/11, Alexander Burger wrote: > So this should be written as > >(be holds (@A @S) > (or > ((restoreSitArg @A @S @F) (@ solve (list (-> @F > ((not (restoreSitArg @A @S @F)) (isAtom @A) (@ solve (list (-> @A ) ) holds(A,S) :- restoreSitArg(A,S,F), F ; \+ restoreSitArg(A,S,F), isAtom(A), A. Now I think that the variables-as-clauses are getting me. In this rule, F might get bound to (unified with?) a clause with variables. For example, F might be bound to something like on(N,s0) When the F clause (now bound to on(N,s0)) is then proved, the N variable in on(N,s0) gets bound to something (3, for example). [trace] ?- holds(on(N), s0 ). Call: (6) holds(on(_G386), s0) ? creep Call: (7) restoreSitArg(on(_G386), s0, _G462) ? creep Exit: (7) restoreSitArg(on(_G386), s0, on(_G386, s0)) ? creep Call: (7) on(_G386, s0) ? creep Exit: (7) on(3, s0) ? creep Exit: (6) holds(on(3), s0) ? creep N = 3 . When I try to do this as (@ (solve (list (-> @F in pilog, taking it through lisp , it prevents the values of the unified vars in @F from being used in the surrounding pilog rule. ? (? (holds (On @N) s0)) -> T ? (solve '((holds (On @N) s0))) -> (T) I wonder what I should do in this case, where a variable can be bound to a clause like that and the variables in that clause need to be bound, too? Cheers, Doug -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe