Re: isc-bind service draft

[ludo@gnu.org (Ludovic Courtès)]

Chris Marusich <cmmarusich@gmail.com> skribis:

> Chris Marusich <cmmarusich@gmail.com> writes:
>
>>>
>>> (define (emit-bind-options-config options)
>>>   (match options
>>>     (($ <bind-options-configuration> user _ run-directory pid-file
>>>                                      listen-v4 listen-v6 listen-port
>>>                                      allow-recursion? allow-transfer?
>>>                                      allow-update?
>>>                                      version hostname server-id)
>>
>> Some of these slots (e.g., listen-v4) appear to be un-used.  Instead of
>> listing positional slots by name, maybe it would be better to bind the
>> entire <bind-options-configuration> to a variable, and then use the
>> accessor procedures (e.g., bind-options-configuration-listen-v4) to get
>> just the attributes you need.  This has the benefit of being more
>> resilient to refactorings which change the order of fields in the
>> record, also.  I realize that a lot of the code in Guix relies on
>> positional matching of slots like this, so I don't mind if you keep it
>> as-is, but consider my suggestion as food for thought.
>
> FYI, I just learned that there is a way to do this with pattern matching
> in Guile.  You can write something like the following:
>
> (match options
>   ((? bind-options-configuration? (= bind-options-configuration-listen-v4 listen-v4))
>    ;; Do something with listen-v4
>    (foo listen-v4)))
>
> As far as I know, this is the same as writing something like:
>
> (match options
>   ((? bind-options-configuration? opts)
>    (let ((listen-v4 (bind-options-configuration-listen-v4 opts)))
>      ;; Do something with listen-v4
>      (foo listen-v4))))

In this particular case I would argue that the second version is more
readable.

Ludo’.