Just closing the loop on your responses. Thank you for combing
through my questions.
> > If 'transaction' is a handle to a currently running transaction why is the predicate called okvs-transaction? I'd expect the type to be called okvs-transaction.
> Well, that should be fixed too. Predicate will be okvs-transaction? and record-type will be <okvs-transaction>. Is that ok?
Yes.
>> 6) What precisely are the semantics of the hash-table returned from okvs-transaction-metadata? Does this documentation need to refer to a particular RnRs or other SRFI?
> Yes, it is a mistake. The hashtable is a R7RS hashtable. Thanks.
>> What happens if I mutate it? :)
> FWIW, it is at the start empty and is intended to be mutated. I use in fstore to keep track of whether the transaction is "dirty" or not. In this context, a transaction is dirty if it has mutated the store.
It's not clear to me how it is intended to be mutated by the user.
It's not clear to me how mutating it impacts other parts of the SRFI.
I will create a topic about it.
>> 8) Could okvs-debug simply be made a degenerate case of okvs-range?
> We briefly discussed that. The idea behind okvs-debug, is that you can use
> it anywhere without transaction ceremony, that is a debug procedure.
> ...
> I am not in favour of removing okvs-debug.
The behavior of a debugging procedure will be unique to the
implementation. For example, how do in-flight transactions appear in
the debugging output?
I don't understand. okvs-debug will start a transaction and go through
the whole database and call PROC with key and value.
It doesn't seem worth standardizing such an
underspecified operation (though no harm in leaving it in the
reference implementation).
I will think about it.
>> 9) What does it mean for the 'home' in (okvs home) to be an address?
> It is implementation dependant. I guess, It is most likely a string.
Maybe use a less overloaded token? Address sounds like a network
endpoint of some sort.
I have no idea what other name to use instead of `home`.
> Like (briefly) discussed in this thread, there seem to be no good reason
> to do an half-open interval.
>
> If what you want is to retrieve all values of a given "space" the space
> must be anyway prefixed with a particular "value" to be able to tell which
> keys are from the space you are interested in.
A "space" prefix is nothing but the half-open interval [prefix, prefix
+ 1). The half-open interval provides space semantics for free, no?
Yes. What should be changed?
>> 15) Why don't all the procedures returning an SRFI-158 generator have some common token in the name? Some are called 'range' while okvs-prefix omits it.
> I am not sure I understand the question correctly.
Sorry to be unclear. If there are a bunch of procedures returning
generators, I would expect them to have similar names. There are
naming consistencies. For example, if okvs-prefix returns a generator
why not have it include 'range' in the name?
Yes, I will (!) rename it okvs-prefix-range
> I hope I answered all the questions correctly.
Absolutely! Thank you for your hard work here.
- Rhys