1) Since SRFI 167 is an interface already, I think that the nstore-engine procedure just needs an okvs object and a prefix.
2) In the nstore procedure, clarify that the prefix of the nstore is appended to the prefix of the engine.
3) Change nstore-ask? to nstore-contains?.
4) I don't see any need for nstore-vars. Just use symbols.
5) It's not clear to me how the variables map onto the non-prefix part of the key/value pair in the underlying okvs. I think there are two plausible approaches: the first element of each tuple is the key, or the first n elements (where n is specific to the nstore) are the key. I prefer the second approach.
6) Have nstore-from's generator return lists, eliminating the dependency on SRFI 146. The car of the list is the key, the cdr is a list of values.
7) Change the name of nstore-from to nstore-select, and nstore-select o nstore-select-where.
8) Tuple matching needs to be defined more clearly. One approach is to use a predicate for each element of the tuple that defines whether this element matches. This matters for both nstore-from and nstore-where.
John Cowan
http://vrici.lojban.org/~cowan xxxxxx@ccil.org"The serene chaos that is Courage, and the phenomenon of Unopened
Consciousness have been known to the Great World eons longer than Extaboulism."
"Why is that?" the woman inquired.
"Because I just made that word up", the Master said wisely.
--Kehlog Albran, The Profit