Re: Brainstorming ideas for define-configuration

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

Bruno Victal <mirai@makinata.eu> skribis:

> User-specified sanitizer support

Yay!

> ;; Suggestion #2
> ;; A user-supplied procedure ('procname' below) would work just like the
> ;; procedure in option #1.
> ;; There is some similiarity to the Guix record-type*.
> ;; This could be extended more easily in the future should it be required.
> (define-type typename        ; maybe call this 'define-configuration-type' ?
>   (sanitizer procname)
>   (maybe-type? #t)
>   ;; The properties below are service specific.
>   ;; If this is implemented with Guix record-type* then we could have a
>   ;; module containing generic types and do something along the lines of:
>   ;; (define-type foo-ip-address
>   ;;    (inherit generic-ip-address)
>   ;;    (serializer ...))
>   (serializer procname)      ; define-type/no-serialization = sets this field to #f ?
>   (prefix ...))

I think we should implement contracts at this point, and have per-field
contracts.  We need to look at what Racket is doing.

> Record Validator
> ===============================================================================
>
> There is also a need to validate records. Matching fields alone do not actually
> ensure that the configuration is coherent and usable. For example, some fields
> may be mutually incompatible with others.

Does that require special support though?  Currently that can be done at
serialization time, for example.

> Coalesced documentation
> ===============================================================================
>
> Currently, we manually edit the texinfo output from configuration->documentation
> if we're unsatisfied with the generated result.
> For instance, substituting @item with an @itemx marker for fields whose
> documentation is similar.

Good idea.

> Serializer access to other fields
> ===============================================================================
>
> Serialization procedures generally only have access to the values of its own field. That
> may be insufficient in some cases as whether a field can be serialized
> or how that is done, for example, can depend on the value of other fields.

Overall, I find it nice that serializers have access to nothing but
their own field value; that makes it easier to reason about the whole
process.

> mympd-service-type is one example where each serialized field depends on the value of
> another field. Our standard serializer procedures were useless for that case.

It’d be interesting to look more closely at this example and see if this
can be solved in some other way or if we really need
‘define-configuration’ support.  Would be nice to see if similar
situations arise with other records.

> Inheritable record-type definition

I’d like to support type inheritance in ‘define-record-type*’, and
‘define-configuration’ could build on top of that.

> Generic serialize-configuration
> ===============================================================================
>
> The procedure serialize-configuration inherently assumes that the serialized
> configuration must be a single string. This assumption needn't always hold, especially
> if the service in question is not a shepherd service.

Hmm, no opinion on that one.

Thanks for the grocery list!  :-)

Ludo’.