From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 04 08:20:33 2022 Received: (at 56799) by debbugs.gnu.org; 4 Aug 2022 12:20:33 +0000 Received: from localhost ([127.0.0.1]:51517 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oJZq4-0007rF-Kn for submit@debbugs.gnu.org; Thu, 04 Aug 2022 08:20:33 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51846) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oJZq2-0007qr-3f for 56799@debbugs.gnu.org; Thu, 04 Aug 2022 08:20:31 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:39248) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJZpw-0000D6-If; Thu, 04 Aug 2022 08:20:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=ctJGBaqTGA7kszIgsr3wp+0jktUuRhB/51rNXucfpMA=; b=BPbVgmJ/M+rRQQmc3LV6 KAp4aJykNmAMJDWkydg8gXaq2HBpqVsCLq+mldzzQvikZh1eeJuf7vAU6G/wTF1cU/IEYLFvurHYF +z9pIUbNIQHL9ktN+HOIJvuSeZ6HyDLcaVVp0Sd8mVMSpKUQQlA812oL0q4N2lspltXKCyfZ4fwZi Y0Fi8taa5ZUV9DyXR7cy6Gw/GxKyuM0LxWnAbSSFuzeKyt52Op84p8AWyTnssUY5zhF3yGb9fGRfL ZiJOeOWvX3d8uRLhpBW0SDW1tsj47kja2pneyl/U6SC+Y03eVzwCrKtL5veuWLnYn7Xi3y0ytbvkZ xxTAjIdx4VAS5A==; Received: from [2001:660:6102:310:f6b5:dff0:8fea:f7c9] (port=46774 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJZpb-0003qu-7X; Thu, 04 Aug 2022 08:20:19 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Maxim Cournoyer Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic References: <87o7xa8qxt.fsf@gmail.com> <8735egxedv.fsf@gnu.org> <87les82c2f.fsf@gmail.com> <87v8rbumnx.fsf@gnu.org> <87sfme1y8m.fsf@gmail.com> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: Septidi 17 Thermidor an 230 de la =?utf-8?Q?R=C3=A9v?= =?utf-8?Q?olution=2C?= jour du Lin X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Thu, 04 Aug 2022 14:19:59 +0200 In-Reply-To: <87sfme1y8m.fsf@gmail.com> (Maxim Cournoyer's message of "Tue, 02 Aug 2022 11:06:17 -0400") Message-ID: <877d3omc9c.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 56799 Cc: 56799@debbugs.gnu.org, attila@lendvai.name X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Howdy, Maxim Cournoyer skribis: >>> Granted, few services outside of Jami probably made use of this, but it >>> was nevertheless a useful property. >> >> I don=E2=80=99t know of any. > > 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: > > (define-configuration/no-serialization xvnc-configuration [...] > (port > maybe-port > "The port on which to listen for connections from viewers. When left > unspecified, it defaults to 5900 plus the display number.") [...] > (define (xvnc-shepherd-service config) > "Return a for Xvnc with CONFIG." > ;; XXX: Ensure all the *unspecified* values are handled outside of gexp= s, as > ;; they are not valid gexp input (they are not self-quoting/serializabl= e). > ;; This would otherwise cause problem during 'guix deploy'. > (let* ((display-number (xvnc-configuration-display-number config)) > (port (if (unspecified? (xvnc-configuration-port config)) > #f > (xvnc-configuration-port config))) OK, I see. I guess most of the time, we just call =E2=80=98serialize-xyz-configuration=E2=80=99, which automatically handles = *unspecified* values. In this case, =E2=80=98port=E2=80=99 is treated specially and inst= ead passed as a command-line argument. Other ways to address that come to mind include: adding =E2=80=98port=E2=80= =99 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=E2=80=99s a mouthful but maybe it could be abstracted. It does sound = less convenient though. That said, whether it=E2=80=99s =E2=80=98unspecified?=E2=80=99 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=E2=80=99s possible whether or not *unspecified* is the default val= ue. WDYT? >> 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 >> 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=E2=80=99d have favored an actua= l revert >> rather than introducing 'unset). > > I like to think of *unspecified* or 'unset as an uninteresting > implementation detail that shouldn't be part of the public API. It is part of the API for people who write services (but it=E2=80=99s defin= itely an implementation detail for someone who just uses services). > 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. 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=E2=80=99s OK. > 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. Right, that makes sense to me. >> How should we move forward? > > Perhaps we can discuss any issues I may have missed that arise from the > this change, or possible future directions that would improve things. With the xvnc example, I better understand the kind of situation where a field value might end up directly in a gexp, though I=E2=80=99m still uns= ure 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=E2=80=99.