bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Tobias Geerinckx-Rice
Subject: bug#56799: (gnu services configuration) usage of *unspecified* is problematic
Date: Wed, 27 Jul 2022 20:45:19 +0200

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.

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.

Kind regards,

T G-R

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]