Alexander Burger wrote:
> Hi Cle,
>   

Hi Alex,

>> 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
>> different.
>>     
>
> 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
regulary :-/

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)
    (@Result make
      (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
c))                                           

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.


Cheers,
cle.

-- 
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe

Reply via email to