From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id mF7JHJ7aQWJpSQAAgWs5BA (envelope-from ) for ; Mon, 28 Mar 2022 17:56:14 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id cBAVFZ7aQWLCSgAAG6o9tA (envelope-from ) for ; Mon, 28 Mar 2022 17:56:14 +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 F3807C655 for ; Mon, 28 Mar 2022 17:56:13 +0200 (CEST) Received: from localhost ([::1]:40730 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nYrj2-0000zm-Ru for larch@yhetil.org; Mon, 28 Mar 2022 11:56:12 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38624) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nYrhj-0000cF-B9 for guix-devel@gnu.org; Mon, 28 Mar 2022 11:54:51 -0400 Received: from [2a02:1800:110:4::f00:19] (port=47652 helo=laurent.telenet-ops.be) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nYrhf-0006DF-FW for guix-devel@gnu.org; Mon, 28 Mar 2022 11:54:49 -0400 Received: from ptr-bvsjgyhxw7psv60dyze.18120a2.ip6.access.telenet.be ([IPv6:2a02:1811:8c09:9d00:3c5f:2eff:feb0:ba5a]) by laurent.telenet-ops.be with bizsmtp id Brui2700s4UW6Th01rui93; Mon, 28 Mar 2022 17:54:43 +0200 Message-ID: Subject: Re: using srfi-189 in (gnu services configuration) From: Maxime Devos To: Attila Lendvai , Ludovic =?ISO-8859-1?Q?Court=E8s?= Date: Mon, 28 Mar 2022 17:54:31 +0200 In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-6WNZsfXGo5Zcms3o0Ic3" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22; t=1648482883; bh=2clnwwtVbwtFhF1tJT2AGS0pNavOGYXkDFPDgZoglyg=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=Dl73TIg56G2qX1a9w4b7X6f7teDwhltGskKRGhP98d6ytxF4fVUXqEB21dwI5IlH6 PSrekO/qFLEkErj3DjOT8XigJN4pZvwC1ECpP1zQcOcvlY7q/BRGyAUabSsKERgv8e Xfbcano6rL1lZaC4eKurL8Z3JGCRx3G4uy6pQKuEgw7NV1gU23oJ+82xKzgIzBZ0xO 1+tVsGLTQNLQGHU4eKkMsgOatiWYxdjDi7QcCZtQjCy6f2/kVJfa2gQE8TaZONAoVh sNNqfQXEGFLf3Cf8JIYuOCGKApjw1kapYmjJl2mQeKVqAJvfp93V7wnvgqaAgplbYy Tyc8TpisXdgSw== X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a02:1800:110:4::f00:19 (failed) Received-SPF: pass client-ip=2a02:1800:110:4::f00:19; envelope-from=maximedevos@telenet.be; helo=laurent.telenet-ops.be X-Spam_score_int: -19 X-Spam_score: -2.0 X-Spam_bar: -- X-Spam_report: (-2.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" 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=1648482974; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=2clnwwtVbwtFhF1tJT2AGS0pNavOGYXkDFPDgZoglyg=; b=MZFNBAEs7GgZzOoUGzA3OC+MIL2cSw65wukfKB65rrijHKFpuwOwVvf1OLvOfzJOArKq6e tg0VhK4A3oi5CEA3oL31fuTte8nywkDpBRskaHYsuD92tDsjWL+eO5GuZCLj504zHv3PRu eipagnORuVtz9NsoQ6779QJ1XuF/bwCGtHF5Cc6ok/dTt4snz0Gyu0d4iBaeVCJgy+ECrm yASNZVzNrnJVYS1prnvEHfpSK3J6pnsCgwdLhXYpacYMnQpb65ehC8uh7ArvC+RgaTe2xO 137Dni6UI/8efnwYRMY+BK8v+KJkSdXOBIzsSGpkbIEMpBYYkuXFOOKgNUz2Uw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1648482974; a=rsa-sha256; cv=none; b=B4RTWMv9s4zRu3jTyug1JdoFeoTTaFuf9rlBhhpi4hv5SxrUDMHHCAzE9oQIATsTqs3wts FnfGxcyohC5n7r94asyTPQl6kO/TEOjrCCjrPl0d8keX/VJeemVkMuLQXHUGOHFlncInc3 UtgeGXpKtofnqDNbnkGdSnrK3emVs78fAhkTw5JqdEN6teNEKBZ361E5I+QpTRSqcnJWQg ClAnY5oPv/Gx9rg2UucPblmfIhX9iIEw4im1NuWlIA3ihvDpqxkpWgY9McL+iY0SapB0Ff Od3brvmfGQtLv0e2T9EdkLhHzkbly1ZHZ3rP48/ACx+dWi5DGFmhUE3W8Dn77w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=telenet.be header.s=r22 header.b=Dl73TIg5; dmarc=pass (policy=none) header.from=telenet.be; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -6.27 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=telenet.be header.s=r22 header.b=Dl73TIg5; dmarc=pass (policy=none) header.from=telenet.be; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: F3807C655 X-Spam-Score: -6.27 X-Migadu-Scanner: scn0.migadu.com X-TUID: OSvEGe+0brJa --=-6WNZsfXGo5Zcms3o0Ic3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Attila Lendvai schreef op ma 28-03-2022 om 14:35 [+0000]: > this is a follow up to: using an SRFI that is not available in Guile >=20 > https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00249.html >=20 > let me summarize the discussion, and with that my argument why i'd > like to use srfi-189 in the configuration code: >=20 > - sometimes we need to be able to unambiguously distinguish whether a > =C2=A0=C2=A0config field value has been specified by the user or not. [..= .] >=20 > =C2=A0=C2=A0in the current setup, simply specifying a default value would= make > =C2=A0=C2=A0it impossible to distinguish, because [...] >=20 > - the current code uses the symbol 'DISABLED It's a bit of a distraction to the discusses issue, but in Guile Scheme, symbols are case-sensitive, so (not (eq? 'disabled 'DISABLED)). > as a special field value > =C2=A0=C2=A0to signify that the field has not been set (i.e. what Nothing= would > =C2=A0=C2=A0mean if we used srfi-189). it is rather confusing, because ma= ny > =C2=A0=C2=A0config fields are boolean fields, where 'DISABLED sounds like= a > =C2=A0=C2=A0valid off value. it is also prone for clashes with user speci= fied > =C2=A0=C2=A0values. >=20 > - the current codebase also uses 'UNDEFINED as yet another special > =C2=A0=C2=A0marker. once i understood, but unfortunately, i have forgotte= n what > =C2=A0=C2=A0for since then... looks like only as a marker in the macro fo= r the > =C2=A0=C2=A0situation when no default value form has been specified for a > =C2=A0=C2=A0field's definition. >=20 > - using symbols as markers for special values is a bad idea, because > =C2=A0=C2=A0the user may specify a field type to be SYMBOL?, which wouldn= 't > =C2=A0=C2=A0error when the value is 'DISABLED. >=20 > - we can't use Guile's *UNSPECIFIED* for this, because the underlying > =C2=A0=C2=A0record implementation of Guile uses it for pretty much the sa= me > =C2=A0=C2=A0thing, and it errors whenever this value is encountered in a > =C2=A0=C2=A0record's field. This does not appear to be true, at least for (srfi srfi-9) records: the following code can put *unspecified* in Guile records without any errors: (use-modules (srfi srfi-9)) (define-record-type (make-foobar foo) foo? (foo foobar-foo)) (pk 'foobar (make-foobar *unspecified*)) ;;; (foobar #< foo: #>) Anyway, even if *unspecified* causes problems, this can be resolved by introducing a new constant like *unspecified* or the symbol 'disabled', but without the potential confusion with a symbol. E.g.: (define-values (*unset-configuration-value* unset-configuration-value?) (let () (define-record-type (*make-unset-configuration-value*) unset-configuration-value? unset-configuration-value?) (values (*make-unset-configuration-value*) unset-configuration-value?))) srfi-189 is also an option, but it seems to me that Haskell-style Maybe/Just/None that would require lots of wrapping and unwrapping which seems a bit tedious to me -- doable and definitely an option, but potentially tedious. Additionally, for your Swarm example, would something like the following work: ;; defined in (gnu services cryptocurrencies) or such (define swarm-testnet (swarm-instance (bootstrap-peers (list "x.y.z.w" "1111:2222:3333::4")) (foo-rate 1.5+2i) ...)) (define swarm-mainnet [...]) (swarm-configuration (ethereum-account ...) (port 12345) ; default: 54321 ;; If the user known what they are doing, they can override ;;=20 (swarms (list swarm-testnet swarm-mainnet))) ? This way, the well-known swarms 'testnet' and 'mainnet' do not have to be special-cased. Greetings, Maxime. --=-6WNZsfXGo5Zcms3o0Ic3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYkHaNxccbWF4aW1lZGV2 b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7p2lAP93syoOqZBbK9iSI/n7+UhKRuft 8No8Cbd2MzZRiCcx2QEArc2ieUYbMBoMAHAf5TYdYD6ttSr7ojbR+cAXM63FUgg= =fOvS -----END PGP SIGNATURE----- --=-6WNZsfXGo5Zcms3o0Ic3--