[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#56799: (gnu services configuration) usage of *unspecified* is proble
From: |
Maxim Cournoyer |
Subject: |
bug#56799: (gnu services configuration) usage of *unspecified* is problematic |
Date: |
Mon, 01 Aug 2022 12:55:19 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) |
Hi,
Tobias Geerinckx-Rice <me@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.
>
>> 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.
OK. The v2 and v3 idea ended up not working, among lesser issues :-).
So I went with v1, renaming the default value to 'unset; see commit
a2b89a3319dc1d621c546855f578acae5baaf6da. Thanks for the naming
suggestions.
I also added a 'jami-provisioning-partial' system test to ensure it
doesn't regress again if we decide to revisit this.
Thanks,
Closing.
Maxim
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, (continued)
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Maxim Cournoyer, 2022/08/09
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Maxim Cournoyer, 2022/08/09
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Attila Lendvai, 2022/08/11
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Maxim Cournoyer, 2022/08/13
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Attila Lendvai, 2022/08/13
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Maxim Cournoyer, 2022/08/13
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Attila Lendvai, 2022/08/16
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Maxim Cournoyer, 2022/08/17
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, (, 2022/08/17
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Maxim Cournoyer, 2022/08/09
bug#56799: (gnu services configuration) usage of *unspecified* is problematic,
Maxim Cournoyer <=