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: 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)






reply via email to

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