Email list hosting service & mailing list manager

engine record is ugly Amirouche Boubekki (05 Oct 2019 22:39 UTC)
Re: engine record is ugly Amirouche Boubekki (05 Oct 2019 22:42 UTC)
Re: engine record is ugly Amirouche Boubekki (24 Oct 2019 07:26 UTC)
Re: engine record is ugly John Cowan (24 Oct 2019 13:39 UTC)
Re: engine record is ugly hga@xxxxxx (24 Oct 2019 15:06 UTC)
Re: engine record is ugly Amirouche Boubekki (25 Oct 2019 08:39 UTC)
Re: engine record is ugly hga@xxxxxx (25 Oct 2019 15:11 UTC)
Re: engine record is ugly Amirouche Boubekki (25 Oct 2019 16:20 UTC)
Re: engine record is ugly John Cowan (25 Oct 2019 16:18 UTC)
Re: engine record is ugly Amirouche Boubekki (25 Oct 2019 16:22 UTC)
Re: engine record is ugly hga@xxxxxx (26 Oct 2019 15:48 UTC)
Re: engine record is ugly Amirouche Boubekki (28 Oct 2019 07:49 UTC)
Re: engine record is ugly hga@xxxxxx (28 Oct 2019 17:04 UTC)
Re: engine record is ugly John Cowan (28 Oct 2019 17:06 UTC)

engine record is ugly Amirouche Boubekki 05 Oct 2019 22:38 UTC

Here the fist paragraph from the SRFI-167 specification about engine:

> engine

> To allow the user of an okvs abstraction (also known as layer) to easily swap implementations, it must be written in terms of the procedures specified in this section. The engine is a simple record of okvs procedures that must be passed to the constructor of layers. It must be shared between okvs implementations. The okvs library must contain an instance of the engine record exported as engine that is bound to the procedures that it defines.

There is error here, the OKVS implementation must have a
(make-default-engine) procedure instead of an "engine" instance, to
follow the lead on make-default-comparator (SRFI-128). That will force
the implementation to choose pack and unpack procedures. That is the
default engine, so I think that is ok. And the (okvs engine) library
provide the necessary procedures to change that.

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 think it is wrong. The idea, is that the have access to the
"procedure" to operate on the okvs
implementation in _generic_ way. The user needs to unwrap the engine.
That leads to those:

  ((foo bar) baz)

calls that I am not familiar with, hence hurts readability.

Instead I would like to code something that looks like the following:

(define (index okvs uid string)
  (okvs-set! okvs (okvs-pack string uid) (okvs-pack #t))))

Based on my knowledge there is an approach to achieve that: Single dispatch.

Do you know what would be the Right Thing? Or maybe this is the Right Thing?

ref: https://srfi.schemers.org/srfi-167/srfi-167.html