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