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)
|
Le dim. 6 oct. 2019 à 00:38, Amirouche Boubekki <xxxxxx@gmail.com> a écrit : > > 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 Maybe chibi-scheme generic is the way to go? ref: http://synthcode.com/scheme/chibi/lib/chibi/generic.html