> From: Amirouche Boubekki <xxxxxx@gmail.com>
> Date: Friday, October 25, 2019 3:39 AM
>
> Le jeu. 24 oct. 2019 à 17:06, <xxxxxx@ancell-ent.com> a écrit :
>
>> For my sdbi I'm doing "engine records" as well, and their ugliness
>> will be visible at this SRFI 167 OKVS level, the sdbi user API level
>> is ~= SRFI 168 Generic Tuple Store Database, which uses OKVSes for
>> its persistence.
>>
>> [ Big snip.]
>>
>> Amirouche is absolutely correct in noting that naive use of this is
>> ugly, where you call a function that returns a procedure to then
>> invoke it, e.g.: (engine-delete engine) "returns the procedure
>> okvs-delete!" for the specific OKVS engine being used.  From a
>> previous message he gave this explanation and example:
>>
>>> Because engine accessors return a procedure, the user needs to write
>>> code that looks like the following
>>>
>>> (define (index okvs engine uid string)
>>>    ((engine-set engine) okvs ((engine-pack engine) string uid)
>>> ((engine-pack engine) #t))))
>>
>> I too would like something more elegant, but I was waiting until I
>> had two different naive implementations to then perhaps wave the
>> magic macro wand, I couldn't see how the Chibi Scheme generic library
>> would solve my issues.
>
> Neither do I.

Thanks for the confirmation.  That generic library looks good for its
intended purpose, dispatching off a few type predicates, but doesn't
really fit our use case.

> The worst thing, in the case of OKVS, is that the user of SRFI-167 and
> SRFI-168 will need to use the "procedure that return a procedure that
> will be invoked immediately". If it was only something internal to
> SRFI-167 / SRFI-168 it would be ok.

There's a US comedy routine where a doctor is told by his patient that
it hurts when he does a particular thing, like stretching his arm in an
unusual way.  The doctor's reply is "Don't do that!"  At least for
SRFI 168 couldn't you hide this detail from the user, as I am at the
equivalent sdbi level?

>> Amirouche, how are you now thinking of doing this?
>
> John recommend to make it an association list. I don't know how it
> will help.

I believe he was recommending that as an alternative to a disjoint type
such as a record, which would require a separate SRFI if it was shared
between your two current SRFIs.

The general idea, which I'm initially using for sdbi per the above I
mostly snipped, is to have two disjoint record types that store the
specific procedures required by the connector and database of choice,
chain which would have most of them, and connection, which includes the
chain being used.

Every subsequent user level operation supplies the connection, and the
code underneath does the currently ugly dereferencing to get the
correct procedure(s) to call.

> If it was just me I would just remove the engine and make SRFI-168
> backend specific. That will be very disappointing. Even if they are
> differences between OKVS implementations, more than between RDBMS, for
> instance FoundationDB has a limit on key and value size unlike
> wiredtiger, it is not documented in sqlite lsm extension. Even if
> there is a size limit, SRFI-168 code can still be used with
> FoundationDB.

That would be seriously unwise, because databases come and go, and the
nice OKVSes we want to use are relatively new.  Apple halted FOSS
updates of FoundationDB for three solid years, and it's only 6 years
old.  WiredTiger's fate is currently bound to MongoDB, a company clearly
having problems with its business model (see the new non-FOSS license).

> We are three to be willing to use predicate based single dispatch.
> Hence, single dispatch is useful.
>
> I am not happy with the time SRFI-167 and SRFI-168 has taken.

I personally think that's OK, they are *the* pioneering Scheme
persistence SRFIs, a lot of the details we hashed out about them have
been invaluable in my sdbi work, and now we've come to another "mattress
in the road" which needs to be removed for both of our efforts.  Plus
you've been working on a number of other valuable things, and for
example generalized John and my desire for constraints etc. into a
spiffy and just finalized hooks SRFI.

> I think amending one or both SRFI later will make things more
> complicated.

That would waste time, and discourage use until they're improved.

> I will work on pre-SRFI for single dispatch and publish in on the
> scheme newsgroup to collect more thoughts.

Why don't we do what you suggest, except have the discussion in the
Schemepersist list, since your and my SRFIs are where we're going to
test this facility out for real, for all levels of users.  As this is a
pain point we're both suffering from right now, we can work on it
immediately and intensely.  *Announcing* this pre-SRFI work on the
newsgroup, Scheme Reddit etc. would be good, though.

- Harold