GNU bug report logs - #60014
[PATCH v2] doc: Clarify special-files-service-type expected value.

Previous Next

Full log

Message #26 received at 60014 <at> debbugs.gnu.org (full text, mbox):

From: Josselin Poiret <dev <at> jpoiret.xyz>
To: mirai <mirai <at> makinata.eu>, 60014 <at> debbugs.gnu.org
Subject: Re: [bug#60014] [PATCH] activation: make install-special-file match
 against pairs as well.
Date: Tue, 13 Dec 2022 11:15:34 +0100

Hi Bruno,

mirai <mirai <at> makinata.eu> writes:

> The documentation for it says:
> --8<---------------cut here---------------start------------->8---
> The value associated with special-files-service-type services must be a list of tuples where the first element is the “special file” and the second element is its target. 
> --8<---------------cut here---------------end--------------->8---
>
> Which I think is the natural way of doing it. (and communicates the intent, a pair with a path and a file-like object.)

Right, that's unfortunate, although that could be changed to “list of
lists” to make it clearer.

> Of course, (list "path" file-like-obj) works as well but imo the pair is clearer in purpose.
> (what meaning would the third element and so on have, if ever present?)
> This I found out the hard way by getting strange errors until I looked into what happens behind
> `special-files-service-type' and realizing that only lists were accepted.
>
> The mixing of cases is unfortunate (it should have been pairs from the start) but preserves
> compatibility with existing syntax. 

I agree with you here, but then I think to avoid having to maintain both
cases at the same time, all existing uses of special-files-service-type
should also be modified, and only one kind should remain, with the other
triggering some deprecation warning.  You could match to `(path
. file-like)`, and if (list? file-like), throw an exception.

As a sidenote, the main problem is that Guile is not a statically typed
language, but that's a whole other debate to have.

In any case, I don't think this patch will be accepted as-is.  I would
only be partially in favor of the second solution (because it breaks
existing code), while the first solution is low-effort and should work
well enough.  Up to you (and maintainers) to decide.

Best,
-- 
Josselin Poiret

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.