From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 22 23:31:31 2021 Received: (at submit) by debbugs.gnu.org; 23 Dec 2021 04:31:31 +0000 Received: from localhost ([127.0.0.1]:60174 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n0FlL-00013Y-EG for submit@debbugs.gnu.org; Wed, 22 Dec 2021 23:31:31 -0500 Received: from lists.gnu.org ([209.51.188.17]:36324) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n0FlJ-00013R-Un for submit@debbugs.gnu.org; Wed, 22 Dec 2021 23:31:30 -0500 Received: from eggs.gnu.org ([209.51.188.92]:59152) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n0FlJ-00059s-Lt for bug-guix@gnu.org; Wed, 22 Dec 2021 23:31:29 -0500 Received: from [2607:f8b0:4864:20::f2f] (port=42538 helo=mail-qv1-xf2f.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n0FlH-0005Fd-Ul for bug-guix@gnu.org; Wed, 22 Dec 2021 23:31:29 -0500 Received: by mail-qv1-xf2f.google.com with SMTP id q4so4149977qvh.9 for ; Wed, 22 Dec 2021 20:31:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=philipmcgrath.com; s=google; h=message-id:date:mime-version:user-agent:content-language:to:from :subject:content-transfer-encoding; bh=9OMq/pqjbd6YPw2p3JoLOo0pP/EXfOC/dJ9XXSgEK3M=; b=O0hu82qLVgL2C8585GAJxyCg07bqTBI/qQljT/UavR4sxSi35xFH0Qb5AADNDPWK6F 44c2hxmrpLxhYQ3z91f25Qgaao0+VvJaV59Z6OtPO8uSuGoQ/2DZDjEN6yml8gd5QC36 uqIBPzfyq297+xgAiTbS/v5M42yLgUjxx93gGH0UduxcXAe8dXRpRACB/SedOWbnXGDe QwPBbrvA2C9JIcT0CnvH9VloQ/juFbwr/PVgIQuAdlWKwBEx4Trni23D+BYcjA7l9Xn2 ywBtQT0b2Un4OsUG/obSHdNW/blh8fqFs1TSqulPq5usmwpLiHeqI6bbNoZ7maJsn/sJ eqbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:from:subject:content-transfer-encoding; bh=9OMq/pqjbd6YPw2p3JoLOo0pP/EXfOC/dJ9XXSgEK3M=; b=og/kV7/QhJFloBCGFc3D6LvmNuiTFTfMRE3MyHVWztFJOCINWW9/A3oWSnDbYTYLee GDCESqXE8Uo3kRDrrVAwylTyyOUIYsblT+k2R+8/8mA1Gx0csvVpHbzgkgMu/63wqUKV ZksM5I7wU7Lb09E+ZsmB0I9YG01Gcn9vyW1mybO3Ob8a94TTJyMtgOSv/vnkWefQ8KQf YdlGZ2fGalFfjmUHC09p2pwjSNyCvZ0zKWTO2zGrtX9+2AabrJ71lDNjWbDjdIx6JT2m kuhb7+xezdYLUz+61rwsu+okhI7VFYbGEdYkw7ApHEBdGHNBQdiY0dr2eSImM2bgIL3o LvaQ== X-Gm-Message-State: AOAM531XPEWhiItLCUDJugh0smTMT21xYP3sSxhS0MYC6XCNeS9GsnPu r4hedRRetl7+xFz9sjPt0snBXTdOvMzMGoHc X-Google-Smtp-Source: ABdhPJwnPPn8cwSyrBMZ2sGomuoOplKVVhOxAOCUdTOrWeOlT86mvDwCnJdR6tGL6mbT4wKD/QXdZA== X-Received: by 2002:a05:6122:a29:: with SMTP id 41mr206982vkn.25.1640233536186; Wed, 22 Dec 2021 20:25:36 -0800 (PST) Received: from [192.168.45.37] (c-73-125-89-242.hsd1.fl.comcast.net. [73.125.89.242]) by smtp.gmail.com with ESMTPSA id i123sm781710vkb.20.2021.12.22.20.25.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Dec 2021 20:25:36 -0800 (PST) Message-ID: <23d2ac1d-737d-787c-5535-c816566461dd@philipmcgrath.com> Date: Wed, 22 Dec 2021 23:25:35 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Content-Language: en-US To: bug-guix@gnu.org From: Philip McGrath Subject: G-expressions don't consistently preserve #nil Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::f2f (failed) Received-SPF: neutral client-ip=2607:f8b0:4864:20::f2f; envelope-from=philip@philipmcgrath.com; helo=mail-qv1-xf2f.google.com X-Spam_score_int: -4 X-Spam_score: -0.5 X-Spam_bar: / X-Spam_report: (-0.5 / 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, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.7 (-) X-Debbugs-Envelope-To: submit 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: -2.7 (--) G-expressions currently do not consistently preserve the distinction between #nil and '(), which causes trouble for programs that rely on that distinction. In particular, the issue affects programs that use (guix build json), because that library uses #nil to represent the JSON value `null', whereas it uses '() to represent an empty JSON array. The following program exposes the error: --8<---------------cut here---------------start------------->8--- (use-modules (guix build json) (guix gexp) (guix monads) (guix store) (guix derivations) (rnrs conditions) (ice-9 textual-ports)) (define (check-equal? actual expected message) (define who 'check-equal?) (unless (equal? actual expected) (raise-exception (condition (make-assertion-violation) (make-who-condition 'check-equal?) (make-irritants-condition (list actual)) (make-message-condition (format #f "~a: ~a\n ~a: ~s\n ~a: ~s\n ~a: ~s" who "test failed" "message" message "expected" expected "actual" actual)))))) (define (sexp->json-string sx) (call-with-output-string (lambda (out) (write-json sx out)))) (define (gexp->json-string gx) (run-with-store (open-connection) (mlet* %store-monad ((drv (gexp->derivation "example.json" (with-imported-modules `((guix build json)) #~(begin (use-modules (guix build json)) (call-with-output-file #$output (lambda (out) (write-json #$gx out))))))) (_built (built-derivations (list drv)))) (return (call-with-input-file (derivation->output-path drv) get-string-all))))) (check-equal? (sexp->json-string '()) "[]" "sexp: empty array") (check-equal? (gexp->json-string #~'()) "[]" "gexp: empty array") (check-equal? (sexp->json-string #nil) "null" "sexp: null") (check-equal? (gexp->json-string #~#nil) "null" "gexp: null") (check-equal? (sexp->json-string '(@ ("k" . #nil))) "{\"k\":null}" "sexp: null in object") ;; This one fails! (check-equal? (gexp->json-string #~'(@ ("k" . #nil))) "{\"k\":null}" "gexp: null in object") --8<---------------cut here---------------end--------------->8--- -Philip From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 23 02:00:03 2021 Received: (at 52749) by debbugs.gnu.org; 23 Dec 2021 07:00:03 +0000 Received: from localhost ([127.0.0.1]:60286 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n0I55-0007Fr-2o for submit@debbugs.gnu.org; Thu, 23 Dec 2021 02:00:03 -0500 Received: from laurent.telenet-ops.be ([195.130.137.89]:40562) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n0I52-0007Et-Ob for 52749@debbugs.gnu.org; Thu, 23 Dec 2021 02:00:01 -0500 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 Zizy2600S4UW6Th01izy37; Thu, 23 Dec 2021 07:59:59 +0100 Message-ID: <6211bc6e48fa8f5dcf8711bba186812f3a5e52c4.camel@telenet.be> Subject: Re: bug#52749: G-expressions don't consistently preserve #nil From: Maxime Devos To: Philip McGrath , 52749@debbugs.gnu.org Date: Thu, 23 Dec 2021 06:59:58 +0000 In-Reply-To: <23d2ac1d-737d-787c-5535-c816566461dd@philipmcgrath.com> References: <23d2ac1d-737d-787c-5535-c816566461dd@philipmcgrath.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r21; t=1640242799; bh=MNHe9HA4c50nMU8nSdazMttb/OLsim/dWTbC8O7ZjBU=; h=Subject:From:To:Date:In-Reply-To:References; b=Lf62nW3+xoQxQeM4vZPt95zigp1Bh6+v+5Tq+0sqggK1xe/EhDzLaLIpOPrj5vd2y 3nD9fUsifMvAcXPgCVj/q6DUU6yaauZLIg97KBHLKhTFRsQGKau4kun+qDhPNHyxZS hqvb4Id9lgtTiO2598rR89zFBwxtG4XGpIwZtwvIvNlVjIxDM+Idn6KUO1aNsxvJYE 1udLoOl6hIC4tFmlnYs4R9OjgXh7u6FuHwUFxOQmDfG6Bt56bOSkOXWtXgQVeumHUB oJ6rPSdvybBX0nndMNCMV1XEtVAmPtL4alBWAQwYBCGLY9KhzUxW615ObxF8/NS4IY gsjOG+Eyk6JsQ== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 52749 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: -1.7 (-) Hi, Philip McGrath schreef op wo 22-12-2021 om 23:25 [-0500]: > G-expressions currently do not consistently preserve the distinction > between #nil and '(), which causes trouble for programs that rely on > that distinction. In particular, the issue affects programs that use > (guix build json), because that library uses #nil to represent the JSON > value `null', whereas it uses '() to represent an empty JSON array. The constant #nil is only for elisp compatibility and not something supposed to be used in Scheme code that isn't for Scheme/elisp compatibility, so this seems more a bug in (guix build json) to me. Greetings, Maxime. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 23 12:58:45 2021 Received: (at 52749) by debbugs.gnu.org; 23 Dec 2021 17:58:45 +0000 Received: from localhost ([127.0.0.1]:34865 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n0SMX-0008Mn-GE for submit@debbugs.gnu.org; Thu, 23 Dec 2021 12:58:45 -0500 Received: from andre.telenet-ops.be ([195.130.132.53]:60254) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n0SMU-0008Me-U2 for 52749@debbugs.gnu.org; Thu, 23 Dec 2021 12:58:44 -0500 Received: from ptr-bvsjgyhxw7psv60dyze.18120a2.ip6.access.telenet.be ([IPv6:2a02:1811:8c09:9d00:3c5f:2eff:feb0:ba5a]) by andre.telenet-ops.be with bizsmtp id Ztyg2600Y4UW6Th01tygcF; Thu, 23 Dec 2021 18:58:41 +0100 Message-ID: <5624d97b0044f4f7e0dc761a590c857e40fc4ed9.camel@telenet.be> Subject: Re: bug#52749: G-expressions don't consistently preserve #nil From: Maxime Devos To: Philip McGrath , 52749@debbugs.gnu.org Date: Thu, 23 Dec 2021 17:58:40 +0000 In-Reply-To: <23d2ac1d-737d-787c-5535-c816566461dd@philipmcgrath.com> References: <23d2ac1d-737d-787c-5535-c816566461dd@philipmcgrath.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r21; t=1640282321; bh=2afgQi2bdc9yrsSWNGVRtfThaEiilUAr155/dlqJLK0=; h=Subject:From:To:Date:In-Reply-To:References; b=E1xhq8rS2XRmjqq6QppS9KjIBcFpTt9KNu7599iTKQxZwbN6DP3RCIgyqTwjuQoiD bEL9KGACuA23VBwgfCT0deJwx7+aV+5jfpWAcPrtBAVtMIMN6bvtlH+ixVYPkrSo+C YJOFynFk6V8Sc0s98sBq6JES2Ke3t22IN3ILWz5KUjaRWejpONClkNkGW9K/RxC5QZ mzKN7Eft5m6F/tVBmHveldL8hlCpbKFovQjLR5IJJbKqUPGhyEAo53dhbqBQxCS2tB inBf7/TgrAWe91bcbGocbGsaYuOh+vxFcz0LLLqh+BFJ37MMMeum3E6TxFA8I9XHyw 78VFDfwdGUurQ== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 52749 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: -1.7 (-) Philip McGrath schreef op wo 22-12-2021 om 23:25 [-0500]: > G-expressions currently do not consistently preserve the distinction > between #nil and '(), which causes trouble for programs that rely on > that distinction. In particular, the issue affects programs that use > (guix build json), because that library uses #nil to represent the JSON > value `null', whereas it uses '() to represent an empty JSON array. > > The following program exposes the error: > [ > ;...] > > ; This one fails! > (check-equal? (gexp->json-string #~'(@ ("k" . #nil))) >                "{\"k\":null}" >                "gexp: null in object") A simpler test: Compare this: (cdr (gexp->approximate-sexp #~("stuff" . #nil))) ; output: #nil --- seems like everything is ok? with: (gexp->approximate-sexp #~("stuff" . #nil)) ; output: ("stuff") --- where did the #nil go? I think the idea is that, if you construct a list (a b c . #nil) in elisp, and pass it to Scheme, then Scheme should treat it as a Scheme list, so it should be printed as (a b c) when using Scheme's 'write' or 'display'. Greetings, Maxime. From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 25 06:13:19 2021 Received: (at 52749) by debbugs.gnu.org; 25 Dec 2021 11:13:19 +0000 Received: from localhost ([127.0.0.1]:38553 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n14zH-0008Ta-31 for submit@debbugs.gnu.org; Sat, 25 Dec 2021 06:13:19 -0500 Received: from andre.telenet-ops.be ([195.130.132.53]:44730) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n14zF-0008TQ-12 for 52749@debbugs.gnu.org; Sat, 25 Dec 2021 06:13:18 -0500 Received: from ptr-bvsjgyhxw7psv60dyze.18120a2.ip6.access.telenet.be ([IPv6:2a02:1811:8c09:9d00:3c5f:2eff:feb0:ba5a]) by andre.telenet-ops.be with bizsmtp id abDE2600r4UW6Th01bDFMC; Sat, 25 Dec 2021 12:13:15 +0100 Message-ID: <637bb8909bd524ce239d66cc73d1e5ad43ce2ea9.camel@telenet.be> Subject: Re: bug#52749: G-expressions don't consistently preserve #nil From: Maxime Devos To: Philip McGrath , 52749@debbugs.gnu.org Date: Sat, 25 Dec 2021 12:13:07 +0100 In-Reply-To: <6211bc6e48fa8f5dcf8711bba186812f3a5e52c4.camel@telenet.be> References: <23d2ac1d-737d-787c-5535-c816566461dd@philipmcgrath.com> <6211bc6e48fa8f5dcf8711bba186812f3a5e52c4.camel@telenet.be> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-EUIZ8heLLU1oMrvohB8k" 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=r21; t=1640430795; bh=M+yDyNpZU8OtyDm9jeaqOI3tlN8msim5zqXR3MdNAtQ=; h=Subject:From:To:Date:In-Reply-To:References; b=JzqUXXG/a82v2xXBLq8m8/wSesDYUna7i0MSZcwrliU3hNhI841X7cboyfuUHTXl8 IF+h9Ts5l3vAJKU595k7qlztYtOCqUjv6qScwi0SHlercmRTbhCqBkOf8DqDdzGmQy mV7rc0hy7KW3RhZrlHFTjURBr8lsZVuqEL+4b1v7INEF+75p7srs1Sz3eQAB7m+Y1c 6KmYoZG63o7L0NJoTeMlr42TMGLfTiDG5skv/VbVkAZZ41G4nSdvs73HOmkPoJ7R1r 4KPpDQCr38vJsY7ok8amXgtLFBSw5B5r78BFiAUGO3dqrbHOWLYsSPqDTA26G6hTZd tF/pASXSe8S1A== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 52749 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: -1.7 (-) --=-EUIZ8heLLU1oMrvohB8k Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Maxime Devos schreef op do 23-12-2021 om 06:59 [+0000]: > Philip McGrath schreef op wo 22-12-2021 om 23:25 [-0500]: > > G-expressions currently do not consistently preserve the distinction= =20 > > between #nil and '(), which causes trouble for programs that rely on= =20 > > that distinction. In particular, the issue affects programs that use= =20 > > (guix build json), because that library uses #nil to represent the JSON= =20 > > value `null', whereas it uses '() to represent an empty JSON array. >=20 > The constant #nil is only for elisp compatibility and not something > supposed to be used in Scheme code that isn't for Scheme/elisp > compatibility, so this seems more a bug in (guix build json) to me. That said, it would be less surprising if the #nil/() distinction is preserved by gexp->derivation and friends. This can be done by writing our own 'write' procedure. Downside: it might be less efficient than Guile's write which is implemented in C. Can be resolved by writing our own 'write' procedure in C. Greetings, Maxime. --=-EUIZ8heLLU1oMrvohB8k 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+4iGRcl7gUCYcb8wxccbWF4aW1lZGV2 b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7n4eAQDc7rGRQG2dwYgOgzrwkVv0iUnv Wo1bt2wxpXEhr0FxrAD/V0TKSYgYTyCcFFMFNn7Mhan/QCa19bozyWYaunweOwo= =/Wmv -----END PGP SIGNATURE----- --=-EUIZ8heLLU1oMrvohB8k-- From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 27 13:38:52 2021 Received: (at 52749) by debbugs.gnu.org; 27 Dec 2021 18:38:52 +0000 Received: from localhost ([127.0.0.1]:44270 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n1utY-0004dw-4D for submit@debbugs.gnu.org; Mon, 27 Dec 2021 13:38:52 -0500 Received: from mail-ua1-f49.google.com ([209.85.222.49]:37464) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n1utV-0004dd-Cg for 52749@debbugs.gnu.org; Mon, 27 Dec 2021 13:38:51 -0500 Received: by mail-ua1-f49.google.com with SMTP id o1so28293920uap.4 for <52749@debbugs.gnu.org>; Mon, 27 Dec 2021 10:38:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=philipmcgrath.com; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=zTuuh5FQuPqoEVX7UROaNCwa0EzUTPl2Nf/0XY3wH+8=; b=jDbFitEBPE4BAIetYCOaKVTYQIRnL2RIHsjqD6xJHjhc9+76ujO6Y1MzTMYWm5yqgl O3ObsXSClRhR2IqPZQObonnby4hyT3e2qeEEjAR/QER+DlCZcst7oQ/DR3JyFkXBpPCC 5k9LTCno1R14XIRppSe7PhZza6X/DxSdLM22eZ8CcHF1f1J5tqG78+Yu6EdrlWVZF87o HYIs9QzX6uzVWCRS/+pj9TCTFnwX5MQK7YdF9oW2r4/kUe+k+Fw0s7H5InRNebUNADUG gwDZE+dDK7DyWSB9WEl4iEbLft/gq48BiYvmx2iQ74KSg9W+DuXDcL9G7cMszRZLQdbY vf+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=zTuuh5FQuPqoEVX7UROaNCwa0EzUTPl2Nf/0XY3wH+8=; b=ZcSBm6djdXVeHhb9wCfMBRYLJ8zOcGOZAJGoWUzh2yIMCRSo3UZk8E0HIzJUaEHzaq z5rVi8oKhJbK/ZWn5+DdOKNDHVuvpRwKiuKVz7J4m6dkpNuqkuaDhvcb1WcmC4MrMUQV xLL7+vYVcKQiuchlt7q8AJku0VZjEMtOGnIng5SrsXkV4veMFuJDd2pzFqUF//mWtQvj RA5BU2Sf86u7n7jyMrXiGttbJWPN8VNspX5tIhYbYi00V+7aqAgp0OlIQlRT5hNWqykM XmjAImgWiPfOYSNnJGLl65bCi6Y8X+JXVbvr5dB2od9T1kEQy5s5GR3Ceyx08gj/R618 mnMg== X-Gm-Message-State: AOAM531v+gk2Zy3c9r6K9hOLNqdKIdVK1TR1vUYvwSWe+yPEDWactY1M To2LeyMXHa2vZnINBQnC4tNcL/kO+efcJVIh X-Google-Smtp-Source: ABdhPJyW7OwfH6AaQYKc+Y4uTESOwfSs/m+si22RX3Fy/MdCd450Db6/B+iORndw19KknHs0jndXGw== X-Received: by 2002:a05:6102:3f4e:: with SMTP id l14mr4959945vsv.2.1640630323674; Mon, 27 Dec 2021 10:38:43 -0800 (PST) Received: from [192.168.45.37] (c-73-125-89-242.hsd1.fl.comcast.net. [73.125.89.242]) by smtp.gmail.com with ESMTPSA id l125sm3135988vke.40.2021.12.27.10.38.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Dec 2021 10:38:43 -0800 (PST) Message-ID: Date: Mon, 27 Dec 2021 13:38:42 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: bug#52749: G-expressions don't consistently preserve #nil Content-Language: en-US To: Maxime Devos , 52749@debbugs.gnu.org References: <23d2ac1d-737d-787c-5535-c816566461dd@philipmcgrath.com> <6211bc6e48fa8f5dcf8711bba186812f3a5e52c4.camel@telenet.be> <637bb8909bd524ce239d66cc73d1e5ad43ce2ea9.camel@telenet.be> From: Philip McGrath In-Reply-To: <637bb8909bd524ce239d66cc73d1e5ad43ce2ea9.camel@telenet.be> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Debbugs-Envelope-To: 52749 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: -0.4 (/) Hi! Just as a general disclaimer, I'm a Racketeer and only incidentally a Schemer, so I'm not very familiar with the universe of Guile libraries. On 12/23/21 01:59, Maxime Devos wrote: > Philip McGrath schreef op wo 22-12-2021 om 23:25 [-0500]: >> G-expressions currently do not consistently preserve the distinction >> between #nil and '(), which causes trouble for programs that rely on >> that distinction. In particular, the issue affects programs that use >> (guix build json), because that library uses #nil to represent the JSON >> value `null', whereas it uses '() to represent an empty JSON array. > > The constant #nil is only for elisp compatibility and not something > supposed to be used in Scheme code that isn't for Scheme/elisp > compatibility, so this seems more a bug in (guix build json) to me. That was not the impression I had gotten from `info "(guile)Nil"`. For example, I think someone who wanted to finish the implementation described in `info "(guile)ECMAScript"` might want to use #nil for one of the false-y ECMAScript values to take advantages of the documented efficiencies in its bit-level representation. More concretely, guile-json@1 and guile-json@3 use #nil in the same way as (guix build json). On 12/23/21 12:58, Maxime Devos wrote: > Philip McGrath schreef op wo 22-12-2021 om 23:25 [-0500]: >> G-expressions currently do not consistently preserve the distinction >> between #nil and '(), which causes trouble for programs that rely on >> that distinction. In particular, the issue affects programs that use >> (guix build json), because that library uses #nil to represent the JSON >> value `null', whereas it uses '() to represent an empty JSON array. >> >> The following program exposes the error: >> [ >> ;...] >> >> ; This one fails! >> (check-equal? (gexp->json-string #~'(@ ("k" . #nil))) >> "{\"k\":null}" >> "gexp: null in object") > > A simpler test: > > Compare this: > (cdr (gexp->approximate-sexp #~("stuff" . #nil))) > ; output: #nil --- seems like everything is ok? > > with: > (gexp->approximate-sexp #~("stuff" . #nil)) > ; output: ("stuff") --- where did the #nil go? > > I think the idea is that, if you construct a list (a b c . #nil) > in elisp, and pass it to Scheme, then Scheme should treat it as a > Scheme list, so it should be printed as (a b c) when using Scheme's > 'write' or 'display'. Since `write` and `list?` are specified by various Scheme standards, I think it is the correct choice for `write` to use a Scheme-compatible external representation for values recognized by `list?`, at least by default. (Perhaps a parameter could control this behavior?) I think the behavior of `gexp->approximate-sexp` is at least defensible, since its documentation (`info guix "gexp->approximate-sexp"`) warns that "some information can be lost". But I think the implementation of G-expressions faces more stringent obligations. I see it as analogous to the implementation of syntax objects, a macro expander, or a compiler, in that it should have a semantics-preserving representation of arbitrary Guile code, including Guile's extensions to Scheme. (I haven't yet understood at a theoretical level how "strata" and "staging" relate to the more familiar concept of "phases", but my intuition is that, while the R6RS model of phases wouldn't be enough, it seems like would probably to express staging/strata in terms of phases with Racket enhancements like the label phase level and arbitrary submodule-implemented phases.) So, I agree that: On 12/25/21 06:13, Maxime Devos wrote: > That said, it would be less surprising if the #nil/() distinction is > preserved by gexp->derivation and friends. This can be done by writing > our own 'write' procedure. Downside: it might be less efficient than > Guile's write which is implemented in C. Can be resolved by writing our > own 'write' procedure in C. I haven't looked at the implementation at all, but extending `write` certainly would be a reasonable option, and, longer-term, it might be possible to upstream a patch adding the needed behavior. A more radical option could be to use a format other than plain-text s-expressions for compiled G-expressions. For example, Racket has a forward-compatible "fast-load serialization" binary format for the kinds of values that can be embedded in compiled code.[0] There are obvious disadvantages to a binary format, but advantages include the ability to preserve source-location information and to avoid some the quirks that come with functions like `write` and `read`, for historical reasons or for the convenience of humans writing code directly. The implementation is in Racket, so it should be fairly easy to port to Guile, if that were wanted.[1] Or maybe there's something related to Guile bytecode that would work, or maybe just making a `#nil`-preserving version of `write` would be easier. -Philip [0]: https://docs.racket-lang.org/reference/fasl.html [1]: https://github.com/racket/racket/blob/master/racket/collects/racket/fasl.rkt From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 27 15:24:30 2021 Received: (at 52749) by debbugs.gnu.org; 27 Dec 2021 20:24:30 +0000 Received: from localhost ([127.0.0.1]:44395 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n1wXl-0001fS-Ra for submit@debbugs.gnu.org; Mon, 27 Dec 2021 15:24:30 -0500 Received: from laurent.telenet-ops.be ([195.130.137.89]:55476) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n1wXh-0001fG-HC for 52749@debbugs.gnu.org; Mon, 27 Dec 2021 15:24:28 -0500 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 bYQP260084UW6Th01YQPm0; Mon, 27 Dec 2021 21:24:23 +0100 Message-ID: <20d06a3f6857a8d30039bc720a9b8c4ecf09702d.camel@telenet.be> Subject: Re: bug#52749: G-expressions don't consistently preserve #nil From: Maxime Devos To: Philip McGrath , 52749@debbugs.gnu.org Date: Mon, 27 Dec 2021 20:24:18 +0000 In-Reply-To: References: <23d2ac1d-737d-787c-5535-c816566461dd@philipmcgrath.com> <6211bc6e48fa8f5dcf8711bba186812f3a5e52c4.camel@telenet.be> <637bb8909bd524ce239d66cc73d1e5ad43ce2ea9.camel@telenet.be> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-tvExMwbCOogf1rDuD/cq" 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=r21; t=1640636663; bh=V3p5emmQiuC3kW2Vglnm+LUvMWvjUgdWe6WJF+Sa2Q4=; h=Subject:From:To:Date:In-Reply-To:References; b=fA08EnNDfKBLrQ+8vCbEZUOgIF1dcky6KFdtImxRxJoi1E7BUAj70gJLJA8zJdvQY pBOmZoVovfrM2/Dxiay0yYdYhF5p6OEL/auX4pVV+euw8BxV3ZHfHsUHt2Zpw+fM+7 MI2II+jiCu1HwsF0idgocMpcZm8f2PknIhIzzDhP/SxYqiGJz7ABDYPrFd7rnVS6Xj qiYiw7GEeUF8Szai83R55oEERXVxGd89van9+lAxeiIY+9ZeoB3oFMSr20yMdI/vLW x2c8IudaM0qaKvZDpqcswxRpoHHEPMWYHN+Fqh7JtBe5KKBJV8Nxsi4KKAwHq03EUH 830a7tWy8k1aw== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 52749 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: -1.7 (-) --=-tvExMwbCOogf1rDuD/cq Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Philip McGrath schreef op ma 27-12-2021 om 13:38 [-0500]: > Hi! >=20 > Just as a general disclaimer, I'm a Racketeer and only incidentally a=20 > Schemer, so I'm not very familiar with the universe of Guile libraries. >=20 > On 12/23/21 01:59, Maxime Devos wrote: > =C2=A0> Philip McGrath schreef op wo 22-12-2021 om 23:25 [-0500]: > =C2=A0>> G-expressions currently do not consistently preserve the distinc= tion > =C2=A0>> between #nil and '(), which causes trouble for programs that rel= y on > =C2=A0>> that distinction. In particular, the issue affects programs that= use > =C2=A0>> (guix build json), because that library uses #nil to represent t= he JSON > =C2=A0>> value `null', whereas it uses '() to represent an empty JSON arr= ay. > =C2=A0> > =C2=A0> The constant #nil is only for elisp compatibility and not somethi= ng > =C2=A0> supposed to be used in Scheme code that isn't for Scheme/elisp > =C2=A0> compatibility, so this seems more a bug in (guix build json) to m= e. >=20 > That was not the impression I had gotten from `info "(guile)Nil"`. For= =20 > example, I think someone who wanted to finish the implementation=20 > described in `info "(guile)ECMAScript"` might want to use #nil for one= =20 > of the false-y ECMAScript values to take advantages of the documented=20 > efficiencies in its bit-level representation. More concretely,=20 > guile-json@1 and guile-json@3 use #nil in the same way as (guix build jso= n). There is =E2=80=98Guile has chosen to support =E2=80=98nil=E2=80=99 as a separate va= lue, distinct from =E2=80=98#f=E2=80=99 and =E2=80=98'()=E2=80=99. This allows existing Schem= e and Elisp code to maintain their current semantics. =E2=80=98nil=E2=80=99, which in Elisp would just = be written and read as =E2=80=98nil=E2=80=99, in Scheme has the external representatio= n =E2=80=98#nil=E2=80=99.=E2=80=99 and =E2=80=98This decision to have =E2=80=98nil=E2=80=99 as a low-level distinc= t value facilitates interoperability between the two languages. Guile has chosen to have Scheme deal with =E2=80=98nil=E2=80=99 as follows: [...]=E2=80=99 and this is only documented under =E2=80=98Emacs Lisp=E2=80=99, though this= doesn't explicitely say it's not supposed to be used elsewhere. Also, see e.g. . Anyway, this doesn't really matter here, because: > So, I agree that: >=20 > On 12/25/21 06:13, Maxime Devos wrote: > > That said, it would be less surprising if the #nil/() distinction is > > preserved by gexp->derivation and friends. This can be done by writing > > our own 'write' procedure. Downside: it might be less efficient than > > Guile's write which is implemented in C. Can be resolved by writing our > > own 'write' procedure in C. > [...] I'll try to look into other parts of your response later. Greetings, Maxime. --=-tvExMwbCOogf1rDuD/cq 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+4iGRcl7gUCYcog8hccbWF4aW1lZGV2 b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7gn5AP9t2YqS7I+2HUBkqSQN1jTC42RV 8wQP0aZeD3BHgHIN2wD/VzrsOL+oHJ+dA3SY8ZSLzajD0HJvpQxs4enH/LUopwE= =ZOjA -----END PGP SIGNATURE----- --=-tvExMwbCOogf1rDuD/cq-- From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 03 05:28:42 2022 Received: (at 52749) by debbugs.gnu.org; 3 Jan 2022 10:28:42 +0000 Received: from localhost ([127.0.0.1]:34207 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n4Ka2-0004Lh-0l for submit@debbugs.gnu.org; Mon, 03 Jan 2022 05:28:42 -0500 Received: from baptiste.telenet-ops.be ([195.130.132.51]:34134) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n4KZx-0004LV-11 for 52749@debbugs.gnu.org; Mon, 03 Jan 2022 05:28:40 -0500 Received: from ptr-bvsjgyhxw7psv60dyze.18120a2.ip6.access.telenet.be ([IPv6:2a02:1811:8c09:9d00:3c5f:2eff:feb0:ba5a]) by baptiste.telenet-ops.be with bizsmtp id eAUa2600Y4UW6Th01AUbXe; Mon, 03 Jan 2022 11:28:35 +0100 Message-ID: Subject: Re: bug#52749: G-expressions don't consistently preserve #nil From: Maxime Devos To: Philip McGrath , 52749@debbugs.gnu.org Date: Mon, 03 Jan 2022 10:28:34 +0000 In-Reply-To: References: <23d2ac1d-737d-787c-5535-c816566461dd@philipmcgrath.com> <6211bc6e48fa8f5dcf8711bba186812f3a5e52c4.camel@telenet.be> <637bb8909bd524ce239d66cc73d1e5ad43ce2ea9.camel@telenet.be> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-KZuPTYXmnUJX4q6rIC6R" 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=r21; t=1641205715; bh=A9vVdpn2puG2qDDMxZE/Rge/GfhH4cTTT6wQcyHzKSQ=; h=Subject:From:To:Date:In-Reply-To:References; b=ZIqgpr2FZBrSXp5Dbih/E0NrWkLDhdfjVjI1vDAS3xaPY1RpBzuDTBjsBMN4eJP7/ +gZEIaShGtXau/XkydutUZFOi0CW+IgrZ4GN7f2tknQdlbRxRKsaBuqv57oCvGYNID Vf30kt3WI1oo8tinX+sFyjz/u6INMBGdklE8kRHClleOeu7224r1RnSDY0fvYu8uS+ 0hc9QcT777QF/eJSLFxowfvtACJ+84gCr3Bzfvz6n7fazFbvkfTkTudOA+Sx4fqiej xgRsXVaL7VxvvHr1NAbOZqJrOHJD/qtmhN2o3jlJNQTmM+Y5duhEDSOQLa0bYOgsYU IjfbqTraAUU0A== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 52749 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: -1.7 (-) --=-KZuPTYXmnUJX4q6rIC6R Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Philip McGrath schreef op ma 27-12-2021 om 13:38 [-0500]: > I think the behavior of `gexp->approximate-sexp` is at least defensible,= =20 > since its documentation (`info guix "gexp->approximate-sexp"`) warns=20 > that "some information can be lost". But no information is lost in this case? $ guix repl > (use-modules (guix gexp)) > (gexp->approximate-sexp #~(a . #nil)) $1 =3D (a) ; sure, the #nil isn't printed ... > (cdr $1) $2 =3D () ; ... also not printed ... > (values (eq? (cdr $1) #nil) (eq? (cdr $1) '())) $3 =3D #t ; but it's still there! $4 =3D #f Greetings, Maxime --=-KZuPTYXmnUJX4q6rIC6R 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+4iGRcl7gUCYdLP0hccbWF4aW1lZGV2 b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7no9AP9qmkinnkmbOY2aj5/hH3V1uG6K cXbOpPbisV4iGr/xmAD8DIxuo4v6ZNaNOspeqtVxUH6M8wmPxu+fiEcAOO6t3gI= =B0iV -----END PGP SIGNATURE----- --=-KZuPTYXmnUJX4q6rIC6R-- From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 03 05:50:03 2022 Received: (at 52749) by debbugs.gnu.org; 3 Jan 2022 10:50:04 +0000 Received: from localhost ([127.0.0.1]:34219 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n4Kuh-0004xA-Fz for submit@debbugs.gnu.org; Mon, 03 Jan 2022 05:50:03 -0500 Received: from andre.telenet-ops.be ([195.130.132.53]:48162) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n4Kuf-0004wf-0X for 52749@debbugs.gnu.org; Mon, 03 Jan 2022 05:50:02 -0500 Received: from ptr-bvsjgyhxw7psv60dyze.18120a2.ip6.access.telenet.be ([IPv6:2a02:1811:8c09:9d00:3c5f:2eff:feb0:ba5a]) by andre.telenet-ops.be with bizsmtp id eApy2600S4UW6Th01ApyTR; Mon, 03 Jan 2022 11:49:59 +0100 Message-ID: <7ec439e7e4115ce927f7d1a87b2663d5468304cc.camel@telenet.be> Subject: Re: bug#52749: G-expressions don't consistently preserve #nil From: Maxime Devos To: Philip McGrath , 52749@debbugs.gnu.org Date: Mon, 03 Jan 2022 10:49:53 +0000 In-Reply-To: References: <23d2ac1d-737d-787c-5535-c816566461dd@philipmcgrath.com> <6211bc6e48fa8f5dcf8711bba186812f3a5e52c4.camel@telenet.be> <637bb8909bd524ce239d66cc73d1e5ad43ce2ea9.camel@telenet.be> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-MLL5WgtVIyjHj8FwQNih" 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=r21; t=1641206999; bh=PPfG0UQkN8RKJZs0tV7/fGeT5Mpzx+E6Ze+aXls0+hk=; h=Subject:From:To:Date:In-Reply-To:References; b=BgXWLaLH1I6S4rEtxsqJ3ZpTaP6hCbtfVbEMRGniUbYr2BlGo/lvpwp6GACZe4TcH leZWhnWZNp8kypxHpe5A+rg+yagGSKivkwBW6PCXnN9pc+iJrNvtXLaAYybRH/FPLC T48jjQqsM/gupXGxv4/CPCj7+Lpq9Ldf50njCLCSKi8sQV8az6EbfejEX0Zas6518a PJ+2GA8Rv4LL7hH2uuUf4PYYDOX5dgVqwubI5qmyUUaWwUjsVt7vDZT+hYcU+Ef8xe BtksXS5jC7yNPyo+P9Po0nBE1x17DDVrh7fVhEwejYZ+MAzw63yIISH8tR0No+YLCC kc2o+rum4uBAg== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 52749 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: -1.7 (-) --=-MLL5WgtVIyjHj8FwQNih Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Philip McGrath schreef op ma 27-12-2021 om 13:38 [-0500]: > I haven't looked at the implementation at all, but extending `write`=20 > certainly would be a reasonable option, and, longer-term, it might be=20 > possible to upstream a patch adding the needed behavior. Not sure what the API should be (an optional argument #:preserve-nil? #true? A parameter nil-writing-style? A procedure 'write-preserving- nil'?), but sure. > A more radical option could be to use a format other than plain-text=20 > s-expressions for compiled G-expressions. For example, Racket has a=20 > forward-compatible "fast-load serialization" binary format for the kinds= =20 > of values that can be embedded in compiled code.[0] There are obvious=20 > disadvantages to a binary format, but advantages include the ability to= =20 > preserve source-location information and to avoid some the quirks that= =20 > come with functions like `write` and `read`, for historical reasons or= =20 > for the convenience of humans writing code directly. The implementation= =20 > is in Racket, so it should be fairly easy to port to Guile, if that were= =20 > wanted.[1] The primary purpose of that data format appears to be able to load S-expressions _fast_, which seems less useful in Guix because every derivations are only built once (ignoring GC and build failures). More important in Guix, is being able to _write_ G-exps fast. Though perhaps fasl can be written fast? Anyway, this fasl format might be one way to represent preserve information. jpoiret on #guix was interested in preserving position information, see . > Or maybe there's something related to Guile bytecode that=20 > would work, or maybe just making a `#nil`-preserving version of `write`= =20 > would be easier. The G-exp machinery doesn't compile things to bytecode, because the bytecode format changes between Guile versions and for bootstrapping, old Guiles are used (from the 2.0 series IIRC). Also, this can lead to world-rebuilds whenever an optimisation in guile is added or tweaked. Anyway, I think that in the short term, it would be easiest to modify (guix build json) to not use #nil (though that would lead to rebuilding all rust and node stuff because it is used in cargo- build-system). Longer term, maybe '(guix build json)' could be eliminated and we could use (json) from 'guile-json' instead, like documented in the manual ((guix)G-Expressions): =E2=80=98In the same vein, sometimes you want to import not just pure-Sc= heme modules, but also =E2=80=9Cextensions=E2=80=9D such as Guile bindings to C = libraries or other =E2=80=9Cfull-blown=E2=80=9D packages. Say you need the =E2=80=98gui= le-json=E2=80=99 package available on the build side, here=E2=80=99s how you would do it: (use-modules (gnu packages guile)) ;for 'guile-json' (with-extensions (list guile-json) (gexp->derivation "something-with-json" #~(begin (use-modules (json)) ...)))=E2=80=99 Greetings, Maxime. --=-MLL5WgtVIyjHj8FwQNih 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+4iGRcl7gUCYdLU0RccbWF4aW1lZGV2 b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7pG4AP0feD6y+Er4BeBoDjOhKfBybZ5W U6KBOKMlRxxtI0UOkgEA3GXdGgjWjhI/m+QL30aZfhMHBNl2ihSvCKy3XUA2JAE= =kTxC -----END PGP SIGNATURE----- --=-MLL5WgtVIyjHj8FwQNih--