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