bug#56799: (gnu services configuration) usage of *unspecified* is problematic

[Attila Lendvai]

> I had used maybe-value-set? because the maybe values are define via the
> 'define-maybe' syntax; they are not really part of
> 'define-configuration' and are sometimes used outside of it, such as in
> (guix home ssh).


oh! i wasn't aware of that.


> An exported variable seems simplest and perhaps less awkward to use,
> e.g. %unset or similar, although it's a bit ugly that we need to reify
> an unspecified value :-).


yeah, i started work on implementing an UNSET! function, and its API
would be unnecessarily complex with a (type, field-name, instance)
signature, and going through generic slot access in its
implementation.


> prepare a patch for the other things mentionned here (an exported
> symbol).


i started implementing your suggestions, including the replacement of
the scattered usage of (eq? 'unset ...) pattern. what i found is that
the code is not very readable using MAYBE-VALUE-SET?, or at least not
for me.

first, it negates the boolean logic everywhere in the current code
(i.e. larger diff, and/or the use of (if (not ...) a b)).

and an example wrt readability:

(if (maybe-value-set? field-default)
    field-default
    (configuration-missing-default-value ...)

a value is never set, only places can be set to some value.

would you be fine if we renamed MAYBE-VALUE-SET? to UNSET-VALUE?

then the boolean logic would remain the same, and the above example
would look like:

(if (unset-value? field-default)
    (configuration-missing-default-value ...)
    field-default)

short of a response i'll continue working towards this in the
following days and send a proposal eventually, but if you're very much
unhappy about it, then let me know!

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
That, which is not falsifiable, can never be true.