Thanks again for the detailed response... here are some follow-up questions. Not critical, but a few answers might satisfy my curiousity...
The easiest thing I can think of is to create a derived index on the classes of elements in your btree and then use map-index to map over the instances. ELE-TESTS> (setf my-things (make-indexed-btree)) ELE-TESTS> (add-index my-things :index-name 'thing-type :key-form '(lambda (index k v) (values t (type-of v)))) ELE-TESTS> (map-index (lambda (sk v pk) (print v)) (get-index my-things 'thing-type) :value 'symbol) OK, this will enable me to grab all of the triples, which is good. But if I understand correctly, it is not associated with *subsequent* efficient search through the results, so I should use idioms like: ELE-TESTS> (add-index my-things :index-name 'triples-first :key-form '(lambda (index k v) (if (subtypep (type-of v) 'triple) (values t (triple-first v)) (values nil nil))) :populate t) [Note that I have fiddled with the `lambda' form you supplied, the original (lambda (index k v) (if (subtypep (type-of v) 'triple) t) (values t (triple-first v)) (values nil nil)) did not make sense to me -- a typo?] You say: This will create an index 'triples-first which only indexes triples and does so by the value of the first element. Thus you can easily retrieve all triples with the first element eq to 5. This sounds good -- but -- I would also like to be able to look up triples by the middle, end, and combinations (like, "match beginning and end"). No problem from the coding point of view, but I want to check that creating all of these indices isn't nuts from the storage point of view. Such additional indices don't take up too much space, right? (I certainly don't have any other better ideas in mind! but thought I should clarify that there may be as many as 7 indices for all the different look-up combinations.) This does create a parallel 'index' which is its own btree. There isn't a good way to do this using only a single btree as we don't expose the sort order constraints or allow the user to create partial keys so they can use cursors to iterate over a subset of the btree. Now if you indexed your things by typename, then you could do this with a single tree, although you'd have to go over indexes Hm, this is an interesting suggestion, but I think it would eliminate the "elegance" (perhaps questionable) of being able to easily and cleanly reach any Thing by its unique ID number (my current strategy). _______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel