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)

Re: engine record is ugly hga@xxxxxx 28 Oct 2019 17:03 UTC

> From: Amirouche Boubekki <xxxxxx@gmail.com>
> Date: Monday, October 28, 2019 2:49 AM
>
> Le sam. 26 oct. 2019 à 17:48, <xxxxxx@ancell-ent.com> a écrit :
>
>>> From: John Cowan <xxxxxx@ccil.org>
>>> Date: Friday, October 25, 2019 11:18 AM
>>>
>>> On Fri, Oct 25, 2019 at 4:39 AM Amirouche Boubekki <xxxxxx@gmail.com> wrote:
>>>
>>>>    ((engine-set engine) okvs ((engine-pack engine) string uid)
>>>> ((engine-pack engine) #t))))
>>>
>>> Ah, I thought the issue was extensibility.  SRFI 128 solves this problem by providing invokers as well as accessors, and in hindsight maybe I should have skipped the accessors.  The general pattern is that the short names like engine-set and engine-pack take an engine object as the first argument and apply the appropriate procedure from the object to the other arguments.  So the lines above become:
>>>
>>> (engine-set engine okvs (engine-pack engine string uid) (engine-pack engine) #t).
>>>
>>
>> There's something I'm missing here, unless you're citing SRFI 128 as an example implementation of the concept you're advocating.
>>
>> To try to make this clear, answering in part one of Amirouche's questions from another posting, the brute force method I'm initially using for sdbi (but haven't yet coded) would in this engine context look like something like:
>>
>> (define-record-type OKVS-Engine
>>   (make-engine engine-set-proc engine-pack-proc etc.)
>>     engine?
>>   (engine-set-proc okvs-engine:engine-set-proc)
>>   (engine-pack-proc okvs-engine:engine-pack-proc)
>>   etc.)
>>
>> (define (engine-set engine-record etc.)
>>   ((okvs-engine:engine-set-proc engine-record) etc.))
>>
>> And would be used something like:
>>
>> (define the-engine (make-engine (lambda (x) x) (lambda (x) x)))
>>
>> (engine-set the-engine 1) ==> 1
>>
>> This only uses accessors, but looking at srfi-128/srfi/128.body1.scm would seem to be an invoker like e.g. comparator-test-type:
>>
>> ;;; Invokers
>>
>> ;; Invoke the test type
>> (define (comparator-test-type comparator obj)
>>   ((comparator-type-test-predicate comparator) obj))
>>
>> It hides the ugliness from the user of the API, pushing it down to the implementor's level, which I and I gather Amirouche would prefer to eliminate altogether.
>
> I just made the change to see how it look like at
> https://github.com/amirouche/arew-scheme/blob/1597d53795da5044d1df176a9cb58bf71093987e/src/arew/srfi/srfi-167/engine.scm#L51
>
> Indeed it is better than relying only on accessors.

Quoting from the file to get this on the record of the mailing lists:

> (define-record-type <engine>
>   (make-engine open
>                etc.)
>   engine?
>   (open %engine-open)
>   etc.)
>
> (define (make-invoker accessor)
>   (lambda (engine . args)
>     (apply (accessor engine) args)))
>
> (define engine-open (make-invoker %engine-open))
> etc.

This is not "ugly", is very straightforward, and looks sufficient for our limited requirement of dispatching on a particular database "engine", technology "chain", etc.  Thanks!

- Harold