[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
signature.asc
Description: PGP signature
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Maxim Cournoyer, 2022/07/27
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Tobias Geerinckx-Rice, 2022/07/27
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Attila Lendvai, 2022/07/27
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Maxim Cournoyer, 2022/07/27
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic,
Tobias Geerinckx-Rice <=
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Maxim Cournoyer, 2022/07/27
- bug#56799: [PATCH] services: configuration: Step back from *unspecified*., Maxim Cournoyer, 2022/07/27
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Maxim Cournoyer, 2022/07/27
- bug#56799: [PATCH v2] gexp: Handle *unspecified* as a gexp input., Maxim Cournoyer, 2022/07/27
- bug#56799: [PATCH v2] gexp: Handle *unspecified* as a gexp input., Maxime Devos, 2022/07/27
- bug#56799: [PATCH v2] gexp: Handle *unspecified* as a gexp input., Maxim Cournoyer, 2022/07/28
- bug#56799: [PATCH v3] gexp: Handle *unspecified* as a gexp input., Maxim Cournoyer, 2022/07/28
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, bokr, 2022/07/28
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Maxime Devos, 2022/07/28
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Maxim Cournoyer, 2022/07/28