> 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 :-/
Yeah, it tries to unify variables with the current Pilog environment.
Gets angry if it doesn't find any env ;-)
> 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)))))
> Perhaps you could have a look and tell me, if there is a quirk somewhere
> hidden in between?
hmm, you could stick with 'solve' (as you did in a previous version):
(be findall (@Var @Pred @Result)
(list (-> @Pred))
(or (val '@Var) (fill (-> @Var))) ) )
> rules, I would like to stay away from Lisp statements within Pilog
> clauses as far as possible. Only if performance really matters or if
But the above version ('make' or 'solve') also calls Lisp ;-)
> 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?
I'm not yet convinced if and why 'findall' is useful. If so, yes.
Otherwise, I would prefer to keep it separate, like other also possible
useful predicates (e.g. 'mapcar' in "misc/pilog.l"). I dont' want to put
too much load on the base system, which is more focused on using Pilog
as a database query engine. For dedicated Prolog programs, a dedicated
library (could also be included into the standard release) might be more