Hi Ludo, Ludovic Courtès <l...@gnu.org> writes:
> Hi! > > Maxim Cournoyer <maxim.courno...@gmail.com> skribis: > >> Since commit 8cb1a49a3998c39f315a4199b7d4a121a6d66449, the >> define-configuration machinery in (gnu services configuration) uses >> *unspecified* instead of 'disabled for an unspecified field value. > > As Attila wrote, the rationale as discussed in > <https://issues.guix.gnu.org/54674> was to specifically use a “special” > value without a read syntax in lieu of a symbol like 'disabled. > >> While this is indeed an improvement in readability, it introduces an >> extra complication: because this new value is not self-quoting, it >> cannot be used as is in G-Exps, and values using it must be carefully >> expanded outside the gexp context, which is error prone. > > Could you give a simple example of how this can happen? > > In my experience, one would use ‘define-maybe’ and appropriate field > serializers such that *unspecified* never goes through. Previously > you’d check for (eq? x 'disabled) and now you just check for > (unspecified? x). Yes, I understand that. What changed is that previously you could have the configuration serialized and used on the service side, which is what using *unspecified* made impossible. Granted, few services outside of Jami probably made use of this, but it was nevertheless a useful property. Thanks, Maxim
