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'?

- Alex
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to