Alexander Burger wrote:
> Hi Cle,
>> And till now, I am failing to get a solution, that works for both
>> examples. I think the problem may be, that in the first example, the
>> free argument '@Var' is unified with the free variable '@C'. But in the
>> second example, '@Var' is bound to '(@C @N)'. Those both seem to work
> Yes, looks like. The binding to '@Var' had already happened before
> exeuction starts.
I thought so! :-(
>> In some Prolog dialects, there is a predicate 'free/1' and 'bound/1'
>> that succeed, if the passed variable was free or bound. Unfortunately, I
>> found no such check in Pilog.
> There is currently no such predicate. Only '->', but this doesn't
> distinguish between "value is NIL" and "not bound".
Perhaps I will give it a try, if I can fiddle something out :-)
> At the moment, however, I don't know how to get the bindings into a
> single result list. I'm sure you know how to make a recursive predicated
> that accomplishes that ;-)
At the first sight, unfortunately not! As every 'cal' to '@Pred' may
deliver only one solution and I will need all, I have to be able to fail
the 'call' to enable Pilog to search for alternatives. But the current
found one I have to add to a list. But adding to a list and failing a
call is somewhat ... tricky?!? ;-)
The usage of 'unify' is interesting, however. I had found it, but did
not understand, how to use it from the manual. It seems, it is only
usable in Lisp statements of Pilog clauses. Otherwise, I got SIGSEGV
But investigating the whole problem further I also came to a solution,
that seem to fit my needs. Here it comes:
(be findall (@Var @Pred @Result)
(for ("Q" (goal (list (-> @Pred))) (prove "Q"))
(bind @ (link (or (val '@Var) (fill (-> @Var)))))
I don't know, how to further improve it, but at least it seem to do what
I need. At least, it will work with those invocations:
: (? (findall @C (ascii @C @N) @L))
@C=NIL @L=(a b c)
: (? (findall (@N @C) (ascii @C @N) @L))
@L=((65 a) (66 b) (67 c))
: (? (findall (convert @N @C) (ascii @C @N) @L))
@L=((convert 65 a) (convert 66 b) (convert 67
Perhaps you could have a look and tell me, if there is a quirk somewhere
hidden in between?
> As my Prolog skills are rather poor, I would more easily come up with a
> Lisp solution. For the problem at hand, it might be useful to know
> that the clauses are stored under the 'T' property of 'ascii':
> : (get 'ascii T)
> -> (((a 97)) ((b 98)) ((c 99)))
I already know this, thank you for the hint :-)
> What is the concrete problem? You might be able to solve it directly
> (and more efficiently) by accessing that list.
Of course I could. But as I write a checker using Pilog clauses as
rules, I would like to stay away from Lisp statements within Pilog
clauses as far as possible. Only if performance really matters or if
something is not solvable without Lisp, I will consider Lisp within Pilog.
As I will have to search for a lot of solutions within Pilog clauses, I
like a generic 'findall' more, than a special weaved clause for every
query I will try later on ... The 'findall' is *one* Pilog clause using
Lisp, those other hand woven ones, were several :-(
Anyway, if we finish our 'findall' would you also consider to put it
into the pilog.l to be included into the standard library?
Thanks for your help.