Alexander Burger <a...@software-lab.de> writes:
>> | (class +a)
>> | (rel a1)
>> | (class +b +a)
>> | (rel b1)
>> | (class +C +b)
>> | (rel C1)
>> | (class +D +a)
>> | (rel D1)
>> | (select a1 +C)
>> | (select a1 +D)
>> both show me all objects that somehow inherited attribute 'a1', although
>> they only have the same root of the class hierarchy (+a), where the
>> attribute is defined, but do not belong to the same branches of the
> I do not know what the relations 'rel' are, i.e. which indexes they have
> and, how these indexes are populated.
yes, sorry, its more a kind of PicoLisp pseudocode ...
> But in general, note that
> (select a1 +C)
> reads "SELECT a1 from C". This means, you specified no search criterion
> at all.
yes, but my point is I specifiy a class +C and I'm surprised that its
superclasses are matched too as well as classes that don't even belong
to the same hierarchy tree but only share the same root classe (where a1
If I search for +Cat with eyes=blue, I would be surprised to find +Tiger
or even +Zebra objects in the result list only because attribute eyes is
defined in common superclass + Mammals.
> If you don't give a relation (index) to search for, 'select' tries to
> find a suitable index by itself by doing some heuristic guesses.
> This is because the PicoLisp database doesn't enforce any attributes or
> indexes, and it highly depends on the application how to find which
> And you should keep in mind that 'select' is just a help for debugging.
> It cannot be used in an application.
ok, wasn't aware of this ...
> For precise searches, use the 'select' and 'db' Pilog queries, or the
> 'db' and 'collect' Lisp functions.