Le ven. 25 oct. 2019 à 17:11, <xxxxxx@ancell-ent.com> a écrit :
>
> > 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.
>

I can not forgo chibi scheme generic library at once. Looking at the tests:

  (define-generic mul)

  (define-method (mul (x number?) (y number?))
    (* x y))

  (define-method (mul (x inexact?) (y inexact?))
    (+ (* x y) 0.1))

  (define-method (mul (x exact?) (y exact?))
    (inexact->exact (call-next-method)))

Based on that it seems like chibi scheme generic would solve the problem.

It brings problems on its own.

Someone will want to discuss  'The Art of the Metaobject Protocol' book [0]
to the discussion or any other OO machinery.

[0] https://en.wikipedia.org/wiki/The_Art_of_the_Metaobject_Protocol

Sadly, I did not read that book. But I am willing to have this discussion or
be pointed to earlier discussion that voted out OO programming from RnRS.

My last few years with Python OO system is that most of the time there is
another way. A simpler way.

> > 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!"

A good amount of sport is good for health, you can even become
addicted to it. Still it hurts.

> At least for SRFI 168 couldn't you hide this detail from the user,

Yes, in SRFI-168 it is hidden. If you want to use it you will need
to rely on okvs-open and okve-in-transaction which are both backend
specific. And where you will end with that pattern:

((engine-open engine) "/var/data/tinycity")

Or

((engine-in-transaction engine)

> as I am at the equivalent sdbi level?

I don't know sdbi code. Can you point me to the code please?

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

At the moment, the engine record is in SRFI-167. I prefer not to do another
SRFI for that because it is really part of SRFI-167. Yes it is shared between
both SRFI.

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

Show me the code. It seems to me, it is a similar mechanic as the engine record.

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

That is exactly like the engine record. Except for opening and
starting transaction
you need to dereference in user code.

Maybe it is not that bad. I read scheme48 code, they rely on a triple
invokation:

(define (apply-generic mtable args)
  ;; (apply (make-generic mtable) args)
  (((method-table-get-perform mtable)) args)) ;+++

It is not user code. What I am thinking is that it might a common
idiom after all.

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

Ok.

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

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

Done.

>
> - Harold