Hi Doug,
> (be do ((Question @P) @S @S) (holds @P @S))
>
> (be holds (@A @S)
> (restoreSitArg @A @S @F)
> (2 cons (-> @F)))
Maybe this mechanism of explicitly specifying a number for the outer
environment for unifying a clause is an an unfortunate limitation of
Pilog. I don't know a better way, though.
As I said, '2' tells the interpreter to unify in "level 2", meaning
the next level outside of 'holds'. So the query
(? (holds (On @N) s0))
works, because you are unifying with the top level.
On the other hand, if you'd defined
(be holds (@A @S)
(restoreSitArg @A @S @F)
(3 cons (-> @F)) )
i.e. specify level '3', the above query would not bind '@N', but the
second query
(? (do (Question (On @N)) s0 s0))
would bind it in turn.
So as long as 'do' doesn't have '@N' in its environment (i.e. the level
above 'hold'), specifying '2' in 'hold' causes the binding to get lost.
I'm not sure if the Pilog interpreter could be easily rewritten to
behave in a better way.
Would it help to use '3' in 'hold'? Or, if you have cases where you also
need '2', to use two versions of 'hold'?
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
