On Mon, Apr 22, 2019 at 1:30 PM Amirouche Boubekki <xxxxxx@gmail.com> wrote:

As of right now the SRFI doesn't expose a predicates for the two disjoint types it expose. Should I add `store?` and `transaction?` predicates to the specification?

Yes.

I am willing to remove the exclamation mark for this three procedures. What do you think?

The notation "!" marks a procedure that changes already existing Scheme locations.  Typically these locations are contained in objects that are passed as arguments, thus "copy") returns new locations, whereas "copy!" side-effects existing ones.  However, side effects outside Scheme are not so marked:  "write" obviously has a side effect on the environment, but it is not written "write!".  So I'd say remove all three.

A more Schemey approach would be (in-transaction database proc failure success), which evaluates proc passing a newly created transaction as its argument.

When proc returns, the transaction is committed and in-transaction applies whatever proc returned to the success procedure and returns its result.

If proc calls "rollback" instead,

then the transaction is rolled back, the execution of proc is abandoned, failure is called with no arguments, and in-transaction returns its result.  By default failure is "raise" and success is "identity".

Right now, procedure "range" is specified to return a generator over the key-value pairs that starts with the parameter PREFIX. This is unlike what FDB does in fdb_transaction_get_range where the range is specified using "start" and "end" bytes. Also see the paragraph about KeySelector. Similarly python bindings of leveldb do specify start and end (ref). I think I will change "range" definition to look more like fdb_transaction_get_range. And add a "store-prefix" procedure that has the same definition as current "store-range" procedure.

Range is more powerful than prefix: for example, it can be used to capture the last 30 days of transactions using the range "20190323" to "20190422".  I'd go with it if I were you, even though it puts more demands on the store.

 

As you can see in the pull-request, I replaced ARGS rest argument with a single CONFIG parameter that is an alist. I think I will also specify the expected keys in that alist along a few expected values, that may or may not be supported by implementations. But when applicable the the configuration must be the same across implementations. That is it will ease portability.

Makes sense. 

We already have, alas, "hashtables," which look to me like things that can be "hasht-ed."  

Well, R6RS does, but R7RS-large uses hash-table.