From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id 0EZzNMnC62ItAAAAbAwnHQ (envelope-from ) for ; Thu, 04 Aug 2022 14:59:53 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id AyyLM8nC62LcGgAAG6o9tA (envelope-from ) for ; Thu, 04 Aug 2022 14:59:53 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 5DC9644F7E for ; Thu, 4 Aug 2022 14:59:53 +0200 (CEST) Received: from localhost ([::1]:50610 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oJaS8-0006V1-Jf for larch@yhetil.org; Thu, 04 Aug 2022 08:59:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36624) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJZqY-0004ou-Kg for bug-guix@gnu.org; Thu, 04 Aug 2022 08:21:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:33535) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oJZqY-0000Lp-Bp for bug-guix@gnu.org; Thu, 04 Aug 2022 08:21:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oJZqY-0007sA-7P for bug-guix@gnu.org; Thu, 04 Aug 2022 08:21:02 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#56799: (gnu services configuration) usage of *unspecified* is problematic Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Thu, 04 Aug 2022 12:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56799 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Maxim Cournoyer Cc: 56799@debbugs.gnu.org, attila@lendvai.name Received: via spool by 56799-submit@debbugs.gnu.org id=B56799.165961563330215 (code B ref 56799); Thu, 04 Aug 2022 12:21:02 +0000 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: Ludovic =?UTF-8?Q?Court=C3=A8s?= 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=A9volution, ?= 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1659617993; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=ctJGBaqTGA7kszIgsr3wp+0jktUuRhB/51rNXucfpMA=; b=tKM8YQP1PXmPen4OHfxur7lVm1TOmLgQCoEG7vVya2jW10J1kWvfeNAS5CzykGcEJguXBJ ruIO4/V57cPqlgLRRXoY02jNZ45TQCl/ZAb3YDTMF/6iwdxAvdpilgpdX4rdPavQsBjwcH nHuyLsOGcDUeDEC2iSEMi13nkI0TuXSzBKltKXOuYjlEG9SB5r7epFpPK/FraP9Ezzc74F QI7tOlK5xO5j2sdvDfAMfUNnNmdLQ57n9AmTpJvjFlycms6Tfbhw1kRaF/kf10n4Pwxq1r VHi82g2zV7J3Fmb2UU/xfEbiIpkmT8kEZplUgmQBKWIbS5dMYZIMWxOOyMJAkA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1659617993; a=rsa-sha256; cv=none; b=Q7LMM6MLcKbSssZqdt+1L5s+YWXqyM2EoIAExZkSd74/jpMc2xZvDOqywC8GLEOadMXqWg /DdZ4kuGZB/AWolHxUa5s/sZ9T9SX6W6Kg5sWSJ3EWUkmJkWQnUpnnYf8KUx174fcu31O3 ufnRwvQQ0K/wWevu1+1jzoX6eqa3lwwh6PitfnjNOjVOvkk9eLZNqWAAsIgRZ9yZjHM7Iv A+/8lViFOeL22+Gcddw4qiAoDqbJ9Y637ichdst0EDu6iAFMic6dy3RWYSqz4GzvQRjzhB WKu8KewO6Co94D4XaiiIMi2zi5DxZ1KdMkEIF2admKRN0+tW0E9u2wlPbu5E/Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gnu.org header.s=fencepost-gnu-org header.b="BPbVgmJ/"; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -2.91 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gnu.org header.s=fencepost-gnu-org header.b="BPbVgmJ/"; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 5DC9644F7E X-Spam-Score: -2.91 X-Migadu-Scanner: scn0.migadu.com X-TUID: /hQm3lrX3uyh 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.