[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#56799: (gnu services configuration) usage of *unspecified* is proble
From: |
Attila Lendvai |
Subject: |
bug#56799: (gnu services configuration) usage of *unspecified* is problematic |
Date: |
Mon, 08 Aug 2022 22:27:32 +0000 |
i got back online...
> That said, whether it’s ‘unspecified?’ or something else, you have to
> have a check in place, right? With the new interface it becomes:
>
> (if (eq? port 'unset) #f port)
>
> Or you can provide an actual default value (an integer in this case),
> but that’s possible whether or not unspecified is the default value.
i agree.
> With the xvnc example, I better understand the kind of situation where
> a field value might end up directly in a gexp, though I’m still unsure
> whether use of unspecified really makes things worse. At least,
> because it lacks a read syntax, the problem is caught early on; whereas
> with 'unset, you might end up stuffing 'unset in your config file
> without noticing.
i agree with this, too.
also, seems like it didn't register in this discussion, so i press it once
again: if the default/unspecified value is a symbol (any symbol), then those
configuration fields, whose type is set to be of symbol, will not error when
they are left unspecified. (see the FIELD-SANITIZER: it simply does a (IF (PRED
VALUE) ...) check, which doesn't fail because 'UNSET satisfies SYMBOL?). i
should have added a unit test for this...
i think moving back from *UNSPECIFIED* to using 'UNSET only has drawbacks. and
if it works (read: it doesn't error out while guix is deploying the config),
then it probably produces illegal config files by serializing the unspecified
value into an "unset" string in the config files.
i'm obviously not aware of the entire complexity here, othrwise there wouldn't
have remained a bug... but regardless of the actual API/value used, i don't see
how any of this could work without the service code explicitly checking for the
unspecified value for fields that have a maybe type (i.e. whose type allows the
value to be unspecified). i think using a symbol instead of *unspecified* only
pushes the appearance of the symptoms farther away both in time and space
(otherwise there should have been a trivial fix to this without changing
*unspecified* back to 'unset).
either way, if there was a failing test case that i could run locally, then i
would have been more than happy to fix it... now i'm only dismayed that all my
service code, and my entire channel got broken. seems like i went offline in
the worst two weeks.
sidenote: what srfi-189 does is basically introduce such a special value that
we are trying to hone in on here (i.e. Nothing, which is implemented as a
record instance) in a standardized way, and also an API to deal with this
special value in various different contexts (i.e. it exports stuff like
MAYBE-IF, MAYBE-FOLD, MAYBE-AND, etc).
https://srfi.schemers.org/srfi-189/srfi-189.html
--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Although teachers do care and do work very, very hard, the institution is
psychopathic-it has no conscience. It rings a bell and the young man in the
middle of writing a poem must close his notebook and move to a different cell
where he must memorize that humans and monkeys derive from a common ancestor.”
— John Taylor Gatto (1935–), 'Dumbing Us Down: The Hidden Curriculum of
Compulsory Education' (1992)
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, (continued)
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Maxime Devos, 2022/08/01
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Ludovic Courtès, 2022/08/01
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Ludovic Courtès, 2022/08/01
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Maxim Cournoyer, 2022/08/01
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Ludovic Courtès, 2022/08/02
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, bokr, 2022/08/02
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Maxim Cournoyer, 2022/08/02
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Ludovic Courtès, 2022/08/04
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Ludovic Courtès, 2022/08/07
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic,
Attila Lendvai <=
- bug#56799: (gnu services configuration) usage of *unspecified* is problematic, Attila Lendvai, 2022/08/08
- 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