GNU bug report logs - #56799
(gnu services configuration) usage of *unspecified* is problematic

Previous Next

Full log

Message #68 received at 56799 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 56799 <at> debbugs.gnu.org, attila <at> lendvai.name
Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified*
 is problematic
Date: Mon, 01 Aug 2022 15:49:32 +0200

Hi!

Maxim Cournoyer <maxim.cournoyer <at> 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).

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.