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

Previous Next

Package: guix;

Reported by: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>

Date: Wed, 27 Jul 2022 16:25:02 UTC

Severity: important

Done: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Tobias Geerinckx-Rice <me <at> tobias.gr>
Cc: 56799 <at> debbugs.gnu.org, attila <at> lendvai.name
Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified*
 is problematic
Date: Wed, 27 Jul 2022 15:09:36 -0400
Hi,

Tobias Geerinckx-Rice <me <at> tobias.gr> writes:

> Hi Maxim,
>
> Maxim Cournoyer 写道:
>> For some background reading, see [0].
>
> Thanks for the well-thought-out reply, and sharing this interesting
> link!
>
> Now, it's just the musings of one person, but now I think I do agree
> with (what I think is) the underlying vision: to hush up *unspecified*
> and sneakily replace it with true nothingness.  OK, I can live with
> that.  :-)
>
>> I think the semantic of the language is that it is to be used as the
>> lack of a return value from a procedure or syntax, e.g.:
>>
>> (unspecified? (if #f 'one-arm-if)) -> #t
>
> Well… in the above context I'd hesitate to even imply
> ‘semantics’. It's like undefined behaviour in C.  Ascribe it meaning
> at your peril.  Otherwise, point taken.
>
>> Having 'unspecified?' even defined in Guile seems to go against that
>> idea; perhaps because Wingo themselves seems to disagree in [0].
>
> Agreed.  *This* was one of my reasons for supporting (field
> *unspecified*), so it's nice to have it validated, even if it is
> rejected.

Good to know I wasn't the only one nudged into thinking the
'unspecified?' procedure somehow justified using *unspecified* directly.

>> I'm also thinking 'unspecified being too close to *unspecified* is
>> probably going to cause confusion down the line.  Reverting to the
>> originally used 'disabled may be the lesser evil.

> Ah, here I can concentrate all my previous disagreement: hell no :-)
>
> It is the worstest evil; literally anything is better than
> (enable-foo? 'disabled) defaulting to #t.
>
> Bikeshed this all y'all want, but 'default or 'unset or 'whatever are
> miles better.

Thanks for sharing your idea!  The neat thing here, is that even if we
disagree about 'unspecified in the patch I'm about to send, we can
discuss it to length then fix the end result in a second using sed ;-).

Thanks for your input!

Maxim




This bug report was last modified 2 years and 326 days ago.

Previous Next


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