[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#56799: (gnu services configuration) usage of *unspecified* is proble
From: |
Attila Lendvai |
Subject: |
bug#56799: (gnu services configuration) usage of *unspecified* is problematic |
Date: |
Sat, 13 Aug 2022 16:47:05 +0000 |
> 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.
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, (continued)
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, bokr, 2022/08/02
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Maxim Cournoyer, 2022/08/02
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Ludovic Courtès, 2022/08/04
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Ludovic Courtès, 2022/08/07
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Attila Lendvai, 2022/08/08
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Attila Lendvai, 2022/08/08
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Maxim Cournoyer, 2022/08/09
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Maxim Cournoyer, 2022/08/09
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Attila Lendvai, 2022/08/11
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Maxim Cournoyer, 2022/08/13
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic,
Attila Lendvai <=
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Maxim Cournoyer, 2022/08/13
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Attila Lendvai, 2022/08/16
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Maxim Cournoyer, 2022/08/17
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, (, 2022/08/17
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Maxim Cournoyer, 2022/08/09
bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Maxim Cournoyer, 2022/08/01