(gnu services configuration) usage of *unspecified* is problematic

Hello Guix,

Since commit 8cb1a49a3998c39f315a4199b7d4a121a6d66449, the

define-configuration machinery in (gnu services configuration) uses

*unspecified* instead of 'disabled for an unspecified field value.

While this is indeed an improvement in readability, it introduces an

extra complication: because this new value is not self-quoting, it

cannot be used as is in G-Exps, and values using it must be carefully

expanded outside the gexp context, which is error prone.

This broke the jami-service-type, when partially specifying a

jami-account like so:

When building the operating system containing the above fragment, the

following error is throw:

The following change to the jami-provisioning test can also reproduce

the problem:

I'd suggest we revisit 8cb1a49a3998c39f315a4199b7d4a121a6d66449 to use

'unspecified (the symbol) instead of *unspecified*, which *can* be

serialized without any fuss in gexps.

Thoughts?

Thanks,

Maxim

Hi Maxim,

Maxim Cournoyer ???

Bah. Could we provide our own reader?

I'd much rather this be addressed in Guile (or failing that,

transparently by Guix) than have to deal with some magical symbol.

IIRC that was the argument for using *unspecified* in the first

place, and I think it makes sense.

This looks more like an unexplored oversight than a well-reasoned

restriction to me.

Kind regards,

T G-R

hi,

sorry for the headaches!

the original discussion is here (well, i think. site is down right now):

'UNSPECIFIED would satisfy SYMBOL?, i.e. a source of headaches/confusion. it used to be 'DISABLED, which was even worse as it can be confused/conflated with a user specified value.

i suggested the use of srfi-189, but it was rejected as unwelcome complexity.

i think it makes sense to change Guile to make *unspecified* self-evaluating, but looking back, maybe the use of srfi-189 would have been better.

i need to run now, and i'll be offline for a week or two. i can't look the example in depth now, but my gut instinct says that it's a bug if *unspecified* reaches any GExp machinery.

more later,

--

• attila lendvai

• PGP: 963F 5D5F 45C7 DFCD 0A39

--

“If you are neutral in situations of injustice, you have chosen the side of the oppressor.”

— Desmond Tutu (1931–)

Hi,

Tobias Geerinckx-Rice <me@tobias.gr> writes:

This was my original impression, but thinking more about it, it became

apparent that *unspecified* is well, unspecified and shouldn't be relied

on by people to be something well defined. For some background reading,

see [0]. So it seems wrong in Scheme to actively set things to

*unspecified*, and give a specific meaning to 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

Having 'unspecified?' even defined in Guile seems to go against that

idea; perhaps because Wingo themselves seems to disagree in [0].

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.

Other thoughts?

Thanks,

Maxim

[0] https://scheme-reports.scheme-reports.narkive.com/QSQtJSAh/unspecified-values

Hi Maxim,

Maxim Cournoyer ???

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

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.

Agreed. *This* was one of my reasons for supporting (field

*unspecified*), so it's nice to have it validated, even if it is

rejected.

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

Hi,

Tobias Geerinckx-Rice <me@tobias.gr> writes:

Good to know I wasn't the only one nudged into thinking the

'unspecified?' procedure somehow justified using *unspecified* directly.

Thanks for sharing your idea! The neat thing here, is that even if we

disagree about 'unspecified in the patch I'm about to send, we can

discuss it to length then fix the end result in a second using sed ;-).

Thanks for your input!

Maxim

Fixes https://issues.guix.gnu.org/56799.

This partially reverts 8cb1a49a3998c39f315a4199b7d4a121a6d66449.

Rationale: *unspecified* cannot be serialized thus used as a G-Expression

input, which is problematic/inconvenient when using deeply nested records. As

an example, jami-service-type was broken when using partially defined

<jami-account> records.

'unspecified symbol.

(normalize-field-type+def): Adjust value to 'unspecified.

(define-configuration-helper): Use 'unspecified as the default value thunk.

'unspecified symbol.

(serialize-maybe-file-object): Likewise.

value.

(raw-content?): Check against 'unspecified symbol.

(prosody-configuration)[http-max-content-size]: Default to 'unspecified.

[http-external-url]: Likewise.

[mod-muc]: Likewise.

[raw-content]: Likewise.

with the 'unspecified symbol.

the 'unspecified symbol.

openvpn-client-configuration and openvpn-server-configuration documentation.

---

doc/guix.texi | 367 +++++++------------------------

gnu/services/configuration.scm | 11 +-

gnu/services/file-sharing.scm | 4 +-

gnu/services/messaging.scm | 12 +-

gnu/services/networking.scm | 6 +-

gnu/services/telephony.scm | 6 +-

tests/services/configuration.scm | 6 +-

7 files changed, 102 insertions(+), 310 deletions(-)

Hi again,

I just sent a first patch.

Another idea would be to add a gexp compiler that would simply turn

*unimplemented* into '*unimplemented* (i.e., quote it). I've never

added a gexp compiler so I don't know how easy/difficult that is.

Thanks,

Maxim

Fixes https://issues.guix.gnu.org/56799.

---

guix/gexp.scm | 2 ++

1 file changed, 2 insertions(+)

On 27-07-2022 22:20, Maxim Cournoyer wrote:

I recommend writing a test case -- this patch does not actually do that.

Instead, it returns the symbol x.

In a ./pre-inst-env guix repl:

I don't know what exact semantics you had in mind but probably not this.

Greetings,

Maxime.

Fixes https://issues.guix.gnu.org/56799.

---

guix/gexp.scm | 2 ++

tests/gexp.scm | 6 ++++++

2 files changed, 8 insertions(+)

Hi,

On +2022-07-27 14:31:32 -0400, Maxim Cournoyer wrote:

Lots of systems are dealing with this issue, it seems, judging from

[1] https://en.wikipedia.org/wiki/Bottom_type

I think the problem is you really need a tuple to return both data and metadata

unambiguously from anything that produces a result (or not, which is a result).

Something like read-delimited with the 'split option, or using catch.

Personally, if I were designing a language :), my goal would be to have

nothing unspecified, and no undefined behaviour outside of physical failures ;-)

*unspecified* seems me like an ok word for the unasserted/high-impedance

state of tri-state memory address bus electronic logic,

but IMO the example above

is not nice. (A nit, but For one thing "specified?" ought to be the question IMO,

if you are ging to have that concept, not "unspecified?" :)

What about using characters from some private upper unicode section

to represent various kinds of unspecified things? E.g.,

as guile named chars,

#\unspecified_function_retval

#\unspecified_function_error

#\unspecified_macro_err

#\unspecified_exception

#\nil or #\not_an_object -- or #\nao -- can't use #\n :)

#\paradox -- e.g., (eval-nl-string "this sentence is lying")

#\nonsense -- e.g. when a question is based on false premises

(eval-nl-string "Bob is bareheaded: Bob, is your hat too tight?")

Hm, one could argue that (+ "ab" "cd") could be based on the false

premise that + was overloaded like

and if it wasn't, should return #\nonsense :)

(though maybe as part of the exception, which is practical for debugging etc :)

#\

#\guix_bottom -- a private unicode rather than U+22A5 which could be

returned as a valid character value by some functon.

Well, hope you can extract something useful from the above :)

BTW, I didn't get far via the link [0] :(

Ok machine, you identified me as human, and kept me out. Happy?

No, I know, machines can only fake that.

--

Regards,

Bengt Richter

On 28-07-2022 06:55, bokr@bokr.com wrote:

I don't think it's a bottom type -- *unspecified* _is_ a value, so if we

assign a type to it, it is inhabited, and hence not a bottom type. I

 suppose you could subdivide the *unspecified* value, but why characters?

I think it would be better to:

* gradually move away from *unspecified* to (values)

* and this way, gradually change the meaning of *unspecified* from "an

unspecified value" to 'an atom you can do with as you want"

* after this, unspecified? and making #<unspecified> readable by the

reader aren't weird anymore

though more something for guile-devel@ I suppose.

Greetings,

Maxime

Hi,

Maxime Devos <maximedevos@telenet.be> writes:

Indeed. Fixed in v3 (which includes a test).

Thanks!

Maxim

Hi Maxime,

Maxime Devos <maximedevos@telenet.be> writes:

[...]

Or perhaps simply introduce a #none or other special syntax similar to

None in Python, that would serve a different purpose that *unspecified*,

and be orthogonal to it. It seems that'd be less confusing and simpler.

Thanks,

Maxim

Hi Attila,

[...]

I don't think it's reasonable to burden users with normalizing their

G-exp input data, where *unspecified* may appear in nested data

structures (such as used by the jami-service-type: jami-accounts has

maybe fields end is used as a nested data type to jami-configuration).

I think v3 of this patch enables us to continue with our current ways

and is a non-invasive change, so I'll merge it soon if there are no

objections.

Thanks,

Maxim

Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

Sadly, this doesn't fix the jami service when using a partially defined

jami-account as part of the jami-configuration; the error is:

Here's what the generated shepherd-jami.scm file look like:

Can you spot where the problem is?

Attached is the extended test I've used to test. You generate a VM

with:

To test with a more hands-on approach.

Thanks,

Maxim

On 01-08-2022 07:08, Maxim Cournoyer wrote:

These lines look suspicious to me -- should they have done (list

*unspecified*) instead of '(*unspecified*)?

The former uses the actual unspecified object, the latter uses the

symbol '*unspecified*' that merely happens to be the name of a variable

the unspecified object is bound to.

Greetings,

Maxime.

Hi,

Maxime Devos <maximedevos@telenet.be> writes:

Indeed; '*unspecified ain't the same as *unspecified, and it isn't

magically evaluated after being lowered in a G-exp:

So in essence the idea to simply quote *unspecified* from patch v3 is

flawed.

v1 works though (using a symbol), so unless someone has a better idea

right now I'm thinking that using 'unset instead of *unspecified* may be

the simplest working solution.

Thanks,

Maxim

Hi!

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

I think we need to take a step back. Overall, I’m reluctant to

modifying a core primitive like ‘gexp->sexp’ “just” to address this

higher-level problem that we have.

Incidentally, this is “unhygienic”, meaning that it relies on

‘*unspecified*’ being bound to what we want. For example, if I do this:

#~(let ((*unspecified* 'hi!))

#$*unspecified*)

… I won’t get the desired output.

Ludo’, who now goes back to the beginning of the thread. :-)

Hi!

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

As Attila wrote, the rationale as discussed in

https://issues.guix.gnu.org/54674 was to specifically use a “special”

value without a read syntax in lieu of a symbol like 'disabled.

Could you give a simple example of how this can happen?

In my experience, one would use ‘define-maybe’ and appropriate field

serializers such that *unspecified* never goes through. Previously

you’d check for (eq? x 'disabled) and now you just check for

(unspecified? x).

Thanks,

Ludo’.

Hi Ludo,

Ludovic Courtès <ludo@gnu.org> writes:

Yes, I understand that. What changed is that previously you could have

the configuration serialized and used on the service side, which is what

using *unspecified* made impossible.

Granted, few services outside of Jami probably made use of this, but it

was nevertheless a useful property.

Thanks,

Maxim

Hi,

Tobias Geerinckx-Rice <me@tobias.gr> writes:

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

Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

Do you have an example? Even on the service side, I imagine one could

check for ‘unspecified?’ just like one would check for 'disabled, no?

I don’t know of any.

Having spent time reviewing the original change that Attila proposed and

then chiming in on this issue, I would have hoped for a longer

discussion before enacting the change in

a2b89a3319dc1d621c546855f578acae5baaf6da.

In addition to these issues around the process, I think we should strive

for more stability. One of the reasons it took time to review

https://issues.guix.gnu.org/54674 is that interface changes are a

commitment. Now commit a2b89a3319dc1d621c546855f578acae5baaf6da

introduces a second interface change for reasons that are unclear to me

(if the conclusion had been to revert, I’d have favored an actual revert

rather than introducing 'unset).

How should we move forward?

Thanks,

Ludo’.

Hi,

On +2022-08-02 09:31:14 +0200, Ludovic Courtès wrote:

My 2¢ :

Maybe separate commmit churn more formally into a

release candidate series like Linus does for linux kernel,

and have a long term stable guix only get what is agreed

with solid consensus?

AND, importantly: where issues involve subtleties

of abstract entities vs their concrete representations,

make sure this is clearly documented in the commit rationale,

e.g., maybe using denottional semantics[1] like r5rs ?

[1]: https://en.wikipedia.org/wiki/Denotational_semantics

:)

--

Regards,

Bengt Richter

OT PS: Has Boot-to-guile been updated by anyone?

Kudos for the original! :) A RISCV qemu image? :)

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

[...]

I think mostly because few services make use of define-configuration.

While attempting to write a new VNC service, it quickly became a visible

annoyance:

As you can see, the *unspecified* values need to be carefully massaged

out before starting to assemble the G-exp, as they aren't valid G-Exp

inputs.

OK.

I like to think of *unspecified* or 'unset as an uninteresting

implementation detail that shouldn't be part of the public API. It's an

implementation detail of the 'maybe' types/predicates generator of the

(gnu services configuration) machinery. Perhaps we could introduce a

'maybe-set?' predicate to check them, to avoid leaking the

implementation detail (the 'unset symbol). Also, after reading more on

the topic, it became clear to me that *unspecified* is not meant as a

value to be actively used by programmers in Scheme; it seems it's rather

a value meant to be returned when the behavior of a procedure is

unspecified [0]. Why 'unspecified?' even exist in Guile I don't know, I

suppose because of some disagreement on the matter, as hinted in the

previous link.

The reason I did not simply revert was because the change also

introduced something useful in the same code change, which is to lift

the requirement to specify a default value for maybe-* fields.

Perhaps we can discuss any issues I may have missed that arise from the

this change, or possible future directions that would improve things.

Thanks,

Maxim

[0] https://scheme-reports.scheme-reports.narkive.com/QSQtJSAh/unspecified-values

Howdy,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

[...]

[...]

OK, I see. I guess most of the time, we just call

‘serialize-xyz-configuration’, which automatically handles *unspecified*

values. In this case, ‘port’ is treated specially and instead passed as

a command-line argument.

Other ways to address that come to mind include: adding ‘port’ to the

config file instead of on the command line (if possible), or doing:

(serialize-configuration config

(find (lambda (field)

(eq? (configuration-field-name field)

'port))

xvnc-configuration-fields))

That’s a mouthful but maybe it could be abstracted. It does sound less

convenient though.

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.

WDYT?

It is part of the API for people who write services (but it’s definitely

an implementation detail for someone who just uses services).

Right, even cleaner would be to have a specific value for this, like:

(define &default-value (list 'default)) ;or something w/o read syntax

(define (default? x) (eq? x &default-value))

But IMO it’s OK.

Right, that makes sense to me.

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.

Thanks for taking the time to discuss!

Ludo’.

Hello,

I just hit this while running ‘guix home reconfigure’ from

f0ae9da3210cc6d87ca519545203daf9751f3465:

home-config.scm:24:16: error: invalid value unset for field 'address-family'

It’s an ‘openssh-host’ record:

(openssh-host

(name "xyz")

(host-name "xyz.example.org")

(user "ludo"))

⇒

#<<openssh-host> %location: #f name: "xyz" host-name: "xyz.example.org" address-family: #<unspecified> identity-file: #<unspecified> port: #<unspecified> user: "ludo" forward-x11?: #f forward-x11-trusted?: #f forward-agent?: #f compression?: #f proxy-command: #<unspecified> host-key-algorithms: #<unspecified> accepted-key-types: #<unspecified> extra-content: "">

We have a new bug to address.

Ludo’.

severity 56799 important

quit

i got back online...

i agree.

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

--

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

sorry, i was wrong/slow here^.

i think i finally understand what the original issue was that triggered the rollback:

the *UNSPECIFIED* value cannot get through the GExp serialize/deserialize operation between the host/builder (or how do we call it?) and Shepherd. the checks in the service code that handle the unspecified field values only happen when Shepeherd is executing the deserialized GExp's.

the fix i would propose is to smarten up GExp serialization to handle whichever value we use as the marker, be it 1) *UNSPECIFIED*, or 2) Nothing from srfi-189, or 3) a record instance that we define/instantiate ourselves.

i don't recommend 3). we should rather use srfi-189 then, because it sandardizes widely known concepts.

so, would you accept a patch that implements 1) or 2) ?

2) has non-trivial uncertainties/complexities in making srfi-189 available in all the required contexts, and not introducing any bootstrap related issues in the process. because of that i would recommend getting to 2) by first implementing 1) and then working towards 2) -- if we want to use srfi-189 at all, that is.

--

• attila lendvai

• PGP: 963F 5D5F 45C7 DFCD 0A39

--

“What's done to children, they will do to society.”

— Karl A. Menninger (http://psychohistory.com/)

Hi,

Ludovic Courtès <ludo@gnu.org> writes:

[...]

Yes, and that provides much welcome flexibility, as records are

serializable (as vectors) so long as the values they contain also are.

Xvnc takes no config switch, and I agree the above is not

intuitive/great. It also wouldn't fix the use case of places it is more

convenient to have the maybe value expanded into the gexp and dealt with

there, such as used in the jami-service-type and in my previous example

making use of a inetd style service, where shepherd-side only bindings

such as endpoint makes it convenient to place the ports logic inside the

service gexp.

To me, the main use of maybe values is to allow for the daemon to use

its own default when no value is specified. A maybe value with a

default value makes little sense to me, so we should move toward

eliminating that style and support for it from define-configuration, in

my opinion. Things would be a bit easier to reason with then.

As a baby step toward making 'unset a properly hidden implementation

detail, I'd suggest the attached patch, which adds a means to check if a

value was set.

[...]

I've been experimenting a lot with define-configuration recently and it

gives you little chance to shoot yourself in the foot; it knows maybe

values are not to be serialized, and won't wrote such values to config

files.

Thanks,

Maxim

Hi Attila,

Attila Lendvai <attila@lendvai.name> writes:

That's the issue, yes! the *unspecified* value cannot cross the

host/build border, which forces someone to pre-compute all things before

serialization happens, which is inconvenient at best in some scenarios I

hinted at (a recent one is defining inetd-style services, which

endpoints need to be computed on the target (inside the service gexp)).

That's what I first attempted, without success. That *unspecified*

expands to some random object on every usage seems meant to discourage

its usage as a specific value (its name, too!)

srfi-189 sounds fancy, but how would it be better than the 'unset

symbol? Could you please restate the problems faced when using a

symbol? Would it be lowerable into Gexp, unlike *unspecified*? To me,

in Guile this means having a readily implemented reader syntax.

As I mentioned earlier, the specific value used for a maybe value is an

implementation detail, or should be made one, in my opinion. So it

doesn't matter to me, as long as it makes writing services convenient

and passes all the tests (I recently augmented the jami-service-type

test which such a case to avoid any regressions).

Thanks,

Maxim

Hi Attila,

Attila Lendvai <attila@lendvai.name> writes:

[...]

OK, I've reread this, and it is indeed a risk, that 'unset could leak in

the case of a serializable configuration making use of a maybe-value

field of type maybe-symbol. I've added the unit test suggested as

97cb43e732a38758c95b7caf3963507188d011cf (currently marked as 'expected

to fail'). Luckily no current service uses that.

I think the tension between serializable vs non-serializable unspecified

values comes from the two kind of usages of define-configuration: one is

to generate config files, in which unspecified means "nothing", and

shouldn't touch disk, while in the case it's used as a more general data

type (define-configuration/no-serialization), there is value in being

able to lower that data type on the build/target so that things can be

lazily computed where needed, without loss of information.

We should add one more unit test to exercise this last usage in action

(currently only jami-service-type makes use of that, but I have an

upcoming Xvnc service that benefits from that as well).

Thanks,

Maxim

thank you for that Maxim!

and sorry for my initial, somewhat reactive, and emotionally driven response earlier! maintaining a channel with complex services, and finally getting the changes i needed merged into Guix proper was a source of frustration for me.

i've looked at the current state of the code, and it looks good to me. the only issues i have left are the following:

1) the (eq 'unset ...) scattered around the code; it should be hidden behind an explicit abstraction, but you yourself mentioned this already in an earlier mail. i'd call it CONFIGURATION-FIELD-SET? (instead of MAYBE-SET?). it's longer, but we have completion in emacs, and it won't be used a gazillion times all around the code either.

2) the lack of an abstraction for the unset/unspecified value. whatever we use as the marker should be hidden behind either an exported global variable, or a function called UNSET-CONFIGURATION-FIELD! (or something alike). i should have introduced these myself, and then your fix would have been as simple as replacing *UNSPECIFIED* with 'UNSET in the abstraction.

3) the SYMBOL? corner case that your test captures, but it's not a burning issue for me (it doesn't affect the user facing API, once the above leakages are fixed).

do you agree? if yes, will you implement it, or shall i prepare a patch?

one more note: sometimes it's useful to have a field with a maybe type that also has a default, together with the ability to explicitly unset this field.

an example would be a port specification for a torrent client: it has some default port, but it's possible to explicitly unset the port value to request the allocation of a random port at startup.

to better accommodate for this use case, 2) should probably be implemented not as an UNSET-FOO! function, but as a global variable holding the unset value marker. or maybe both?

--

• attila lendvai

• PGP: 963F 5D5F 45C7 DFCD 0A39

--

“There is only one thing more harmful to society than an elected official forgetting the promises he made in order to get elected; that's when he doesn't forget them.”

— John McCarthy (1927–2011), father of Lisp

Hi Attila!

Attila Lendvai <attila@lendvai.name> writes:

No worries. We all get caught in emotions at times. It's not

necessarily a bad thing, it's a sign we are invested and care.

I had used maybe-value-set? because the maybe values are define via the

'define-maybe' syntax; they are not really part of

'define-configuration' and are sometimes used outside of it, such as in

(guix home ssh).

An exported variable seems simplest and perhaps less awkward to use,

e.g. %unset or similar, although it's a bit ugly that we need to reify

an unspecified value :-).

I sent a patch somewhere for the maybe-value-set?, see message-id

<87bkstnd2d.fsf@gmail.com> up this thread. I'd be happy if you could

prepare a patch for the other things mentionned here (an exported

symbol).

True. I'd prefer if this never was true for simplicity (a maybe field

would not need to take a default value), but the reality is that we may

want to set a sane default value while allowing the user to clear the

field to have the software use its default behavior.

I'd keep things simple with the exported unspecified value rather than

both. A single, obvious way to do things is simpler.

Thanks,

Maxim

oh! i wasn't aware of that.

yeah, i started work on implementing an UNSET! function, and its API

would be unnecessarily complex with a (type, field-name, instance)

signature, and going through generic slot access in its

implementation.

i started implementing your suggestions, including the replacement of

the scattered usage of (eq? 'unset ...) pattern. what i found is that

the code is not very readable using MAYBE-VALUE-SET?, or at least not

for me.

first, it negates the boolean logic everywhere in the current code

(i.e. larger diff, and/or the use of (if (not ...) a b)).

and an example wrt readability:

(if (maybe-value-set? field-default)

field-default

(configuration-missing-default-value ...)

a value is never set, only places can be set to some value.

would you be fine if we renamed MAYBE-VALUE-SET? to UNSET-VALUE?

then the boolean logic would remain the same, and the above example

would look like:

(if (unset-value? field-default)

(configuration-missing-default-value ...)

field-default)

short of a response i'll continue working towards this in the

following days and send a proposal eventually, but if you're very much

unhappy about it, then let me know!

--

• attila lendvai

• PGP: 963F 5D5F 45C7 DFCD 0A39

--

That, which is not falsifiable, can never be true.

Hi Attila,

Attila Lendvai <attila@lendvai.name> writes:

[...]

Thanks!

It's not clear to me why you think the above is less readable; in the

code I had to touch, the maybe-value-set? was more natural, as the cases

I dealt with often tested for (not (eq? 'unset ...)), so reversing the

logic allowed getting rid of the negation. See

https://issues.guix.gnu.org/57168#13for example.

unset-value? sounds like an action; so I'd name it 'maybe-value-unset?';

but as I wrote above I don't really see the benefit/like the idea.

Thanks for working on it!

Maxim

it's always funny when two non-native speakers (?) argue about english... :) maybe we should invite one into the conversation?

with that in mind: UNSET-VALUE? certainly doesn't look like an action to me due to the question mark at the end. if we want to clearly disambiguate this, then we should insert 'is' somewhere, e.g. IS-UNSET-VALUE? which is a short version of IS-IT-THE-UNSET-VALUE?, i.e. it is not a shorthand for IS-THIS-VALUE-UNSET?, because only places can be in the state of not set.

does this clarify my perspective?

it's not crucial, though. i can work my way through the changes without renaming this, but it'll be public API, so it's better to have something intuitive and non-misleading published at the earliest possible iteration.

--

• attila lendvai

• PGP: 963F 5D5F 45C7 DFCD 0A39

--

“I sincerely believe that banking establishments are more dangerous than standing armies, and that the principle of spending money to be paid by posterity, under the name of funding, is but swindling futurity on a large scale.”

— Thomas Jefferson (1743–1826)

Hi Attila,

Attila Lendvai <attila@lendvai.name> writes:

Eh. I'm not a native English speaker either (although living in North

America you can't really escape being exposed to it), but the naming

issue here seems logical rather than subjective to me: unset can be both

a verb or an adjective; by moving it after the noun, it communicates

better that it acts as an adjective rather than as a verb.

So instead of 'unset-value?', I'd use 'value-unset?', but since in this

case we're dealing with a 'maybe' type defined with the 'define-maybe'

macro, I'd keep 'maybe-value-unset?'.

I hope this makes sense.

Native English speakers are welcome to tip in, of course :-).

Thanks,

Maxim

Hello Maxim,

On Wed Aug 17, 2022 at 2:16 PM BST, Maxim Cournoyer wrote:

How about `unset?` or `maybe-unset?`? (I am a native English speaker, but

to be honest I don't think that really matters much to this dicussion...)

-- (

(normalize-field-type+def): Use it.

(maybe-value-unset?): Use it.

---

gnu/services/configuration.scm | 16 +++++++++++++---

1 file changed, 13 insertions(+), 3 deletions(-)

---

gnu/services/configuration.scm | 10 ++++++++++

1 file changed, 10 insertions(+)

usage of 'maybe-string' with a default value, which doesn't make sense.

---

doc/guix.texi | 7 ++++++-

gnu/services/configuration.scm | 15 ++++++++++-----

2 files changed, 16 insertions(+), 6 deletions(-)

the maybe infrastructure.

(serialize-maybe-file-object): Use maybe-value-set?.

internals in unset field declarations.

(getmail-destination-configuration): Ditto.

(prosody-configuration): Use %unset-value.

(archive-name->username): Use maybe-value-set?.

%unset-value.

---

gnu/home/services/ssh.scm | 12 +++++++-----

gnu/services/file-sharing.scm | 11 ++++-------

gnu/services/getmail.scm | 6 +++---

gnu/services/kerberos.scm | 1 +

gnu/services/messaging.scm | 15 ++++++++++-----

gnu/services/networking.scm | 2 +-

gnu/services/telephony.scm | 6 +++---

tests/services/configuration.scm | 2 +-

8 files changed, 30 insertions(+), 25 deletions(-)

The new value of %unset-value sticks out more when something goes wrong, and

is also more unique; i.e. easier to search for.

---

gnu/services/configuration.scm | 5 +++--

gnu/services/messaging.scm | 2 +-

tests/services/configuration.scm | 2 +-

3 files changed, 5 insertions(+), 4 deletions(-)

Hi Attila,

Attila Lendvai <attila@lendvai.name> writes:

Thanks for the series! I've now pushed all of the 5 commits. Yay!

Closing!

Maxim

Hi,

Attila Lendvai <attila@lendvai.name> writes:

[...]

maybe-value-set? cannot be used there, as the code runs on the target,

not on the host, where (gnu services configuration) is not (and cannot)

be in scope.

I've made the simple change below and pushed:

I've also adjusted a few 'unset mentions in the doc:

I've made these changes and pushed, as mentioned in a previous email.

Thank you!

Maxim