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.
>
> Specifically an opaque "chain" record type, which is used to set up your "stack" of "technologies", for instance:
>
> (db-chain-construct alist) -> chain
>
> Where the alist requires at least two entries, one 'connector, currently like 'postgresql-net or 'sqlite3-ffi (because the "net" or "ffi" come after the connector, how it talks to the database, they're always linked).  It's their job to supply a generic interface to the code above them to do database operations.  And one to specify the database, because they have generic behavior as well as quirks to either be homogenized, or deliberately exposed, like SQLite3's functions to convert dates and time to and from text.  E.g.:
>
> (db-chain-construct '((connector . cassandra-ffi)
>                       (database . cassandra)))
>
> That chain record is then handed to (db-connection-open chain alist) which returns another opaque type, connection, and subsequent calls to procedures like (db-exec connection statement) will in whatever way use the connection record to know which connector and and database procedures to call.
>
> 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. 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.

> 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.

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.

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 think
amending one or both SRFI later will make things more complicated.

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