From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Dr. Arne Babenhauserheide" Newsgroups: gmane.lisp.guile.user Subject: Re: Breaking hygiene with syntax-rules? Date: Fri, 11 Aug 2023 07:07:17 +0200 Message-ID: <87bkfe16xn.fsf@web.de> References: Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3178"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.10.5; emacs 29.0.92 Cc: guile-user@gnu.org To: Walter Lewis Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Fri Aug 11 07:32:06 2023 Return-path: Envelope-to: guile-user@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qUKko-0000eH-BP for guile-user@m.gmane-mx.org; Fri, 11 Aug 2023 07:32:06 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qUKkE-0002g2-K1; Fri, 11 Aug 2023 01:31:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qUKkB-0002fp-Pb for guile-user@gnu.org; Fri, 11 Aug 2023 01:31:27 -0400 Original-Received: from mout.web.de ([212.227.17.11]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qUKk9-0006MB-Of for guile-user@gnu.org; Fri, 11 Aug 2023 01:31:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=s29768273; t=1691731883; x=1692336683; i=arne_bab@web.de; bh=tASP3jRYNeVZcCpzFL3V3PJbD4/2Y13+IrqaqMblCns=; h=X-UI-Sender-Class:References:From:To:Cc:Subject:Date:In-reply-to; b=VKrf/PawMl3Y8K+A854W+MEHksEm52izjGrdZk4bM8iqMRU0Ra1PF4LKXELLrtupV0KYjeV dxHrppBGlBUlx1bDaJF8Xej0NSFyAWSs0AMw3uW7au1LHRJ39imojN2ZK6EPSRDhsKbkesu6r zMPPK+ULfZ2XiaTvG/uGfmXReiSVAlop0JU7kWZWkSak5FAJPuQD/I/Xw35WfyEv8UGAaRMiH Qg0aHkUkQ9h1+4XQkR3xxwJSfARs5e6F9LO3jNaHwahuiDlQGufeYluaxtiDglPfW/IE+/xmt 0KUbVzIQF9KbaV60dTGlY4UkM15OHIkEEs3IbSXLKgD7+1Ebm9gQ== X-UI-Sender-Class: 814a7b36-bfc1-4dae-8640-3722d8ec6cd6 Original-Received: from fluss ([84.165.27.117]) by smtp.web.de (mrweb106 [213.165.67.124]) with ESMTPSA (Nemesis) id 1MIL4Y-1qXgFz16o8-00EQnV; Fri, 11 Aug 2023 07:31:23 +0200 In-reply-to: X-Provags-ID: V03:K1:eUpveU56DjVhw1jEkeqRuQXqO5KukzbF1SdN4e0bV3DZqoLtV0D Cnmmz8a2uJVSeD/nDdCpdYZkazBD2ai9Cnr8RyLkut6ddyeiO7fjC6HM8VVExUzk2D6vhyO FdK4/q8QjYzj93Fm50KTavasd/CpQVPIk4gWrNrvTY8SfP/o+4f3uOYH+XpcqcdTQ81QUQX 4nWTzFv7pkBq3hLsAaHDg== UI-OutboundReport: notjunk:1;M01:P0:+Y1+baVLgMY=;3a3v1iM6pZ0/ItX4qfKCwvlxJC8 xSz+de+B+aqEmjv+87U6vW1bYpVE+Cvw+DvX/TpmAMzuldwUVsL1CxzElHyyGkUpX/SRd6/9Y Ex/tPqKRDcHz6+j0HVddS5WS5myXKyzofOd9rWxnneLYj38agIW7lTMkwJgV8sPRmxeRaRWuF lgqSiADqW595EP7e+jljMRI3gdpiX+T617qAAuzsOpyA2JNdQkbmOizx4doRKhG8kRtIF+6FN K2a00miM9Uk/upKUFc21BxR0COhTdsvM4hJv9dyoFzfGnlUcdQmziTFT5RB3mx2OBJjgd1ufS 2Fx1FTPDYTUcYcfADkJrLeXTdtoSRT4vheK3iy68FECuItox354eDwd0zJ1tExDgd4iH1raq+ 0xVpgZx4GNvtN1GXr0v2rDmG7H5o1RMbJD0GR16P0upJq6LcC4ToiqDkntTC1OVQfLSdE8lDw QRc/Z8Bhpm5FSqjDCtj4/9qDkk6147qh/PUat8xXPng05rQRLfZ9UcEQqyYplJwK85PjalwMz DvFK5peYxMBRnCgaiDwsKWgfEB0BFGolaL7Q/FylBSfhKKn7O9BRDgKGI33qcWfizLt6o4jJ3 tsCmQuJ532Hc4O/yU7bOg1F+zDBUYEvK/F/fjVNctkfYGQ2OKxVEMD8jkGdtZDuwgqYaY6msR /KlaRUkUfvM+2pCWLsKd8xNxNhlN5Q8jf7cxLF+1T7prfhzxCdmxZIvKfeaxlE7NmIlZF1sBK aK9NuCwpkMm0NQzuzX93mRbQ2WKqZ+dclAMUVFe8vx+uvr7sRyFbfdXXChv0CEjamlrXzvq8 Received-SPF: pass client-ip=212.227.17.11; envelope-from=arne_bab@web.de; helo=mout.web.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.user:19143 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Walter Lewis via General Guile related discussions wri= tes: > (define-syntax unhygienic > (syntax-rules () > ((_ the-pair fetch) > (begin > (define the-head (car the-pair)) > (define (fetch) the-head))))) > > (unhygienic '(1) fetch1) > (unhygienic '(2) fetch2) > > (fetch1) > > ;; =3D> 2 I just tested this and see the same problem: (unhygienic '(a) name1) (unhygienic '(b) name2) (name1) ;; =3D> b (name2) ;; =3D> b So it=E2=80=99s reproduced. Thank you for the minimal example! > It seems that the second call to unhygienic shadows the previous > definition of the-head. I expected syntax-rules to generate fresh > names for it each time. > > Is this expected, and if so, is there any way to generate an internal > definition using syntax-rules? For my case, I was writing a macro to > generate SRFI-9 record definitions, but I noticed some of the getters > and setters which I intended to be private were shadowing each other. I did not expect this. To track this: (define-syntax unhygienic (syntax-rules () ((_ the-pair fetch) (begin (define the-head (car the-pair)) (define (the-proc) the-head) (define (fetch) the-head) (display the-proc))))) (display the-head) ;; =3D> error Unbound variable: the-head (step out of the debugger with C-d) (unhygienic '(a) name1) ;; =3D> # (the proc has a long suff= ix, looks good) (display the-head) ;; =3D> error: Unbound variable: the-head (looks good?) (name1) ;; =3D> a (unhygienic '(b) name2) ;; # (the suffix of the proc is the= same as for the one in a?) (name1) ;; =3D> b Maybe this is just, because the procedure is *the same*? Let=E2=80=99s use fetch in the-proc: (define-syntax unhygienic (syntax-rules () ((_ the-pair fetch) (begin (define the-head (car the-pair)) (define (the-proc) fetch)=20=20=20 (define (fetch) the-head) (display the-proc))))) (unhygienic '(a) name1) ;; =3D> # (unhygienic '(b) name2) ;; =3D> # (name1) ;; =3D> b Now the proc is no longer the same, but the variable still collides. Auto-completion in the REPL the-head- ;; =3D> the-head-3f6c11022fffe02 the-head also has a suffix, as it should have, but there is only one. Does the counter go wrong? One more check: (define-syntax unhygienic (syntax-rules () ((_ the-pair fetch) (begin (define the-head fetch) (define (the-proc) fetch)=20=20=20 (define (fetch) the-head) (display the-proc))))) Now using fetch in the-head I get two different variables in the shell. Maybe detection of external data is missing that the-pair is external? Best wishes, Arne =2D-=20 Unpolitisch sein hei=C3=9Ft politisch sein, ohne es zu merken. draketo.de --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJEBAEBCAAuFiEE801qEjXQSQPNItXAE++NRSQDw+sFAmTVx6YQHGFybmVfYmFi QHdlYi5kZQAKCRAT741FJAPD672qD/9Q/ht48D7/vaP7O12SBH4CmlNwmqxO/Urm 0C+7Y34iCsXh23iFJqHaTGqo6amg+KtbAnzEhHxIHuIgjoUHiqOWQsAb9X/iMFPV lN5R6RrGtdQIQQzwvi/W6f8ZLfBQDITNGAhpo2qY0O2Rvcu9/crPQ56+KqeLLSvz pewo94K+qCpr+22zSgIWKqiOJN7RnU0fuklXGv4rh7y16r2Y1ng5qLxq9NvDBEag kozL6oFg98KLjOwsM4zURkhkzVeazNd+U9l8Q9Yn4NiL32XCn1pXRX3NMLb/SwpL 658mM0761wq1GzukN5HXWP/kv+ftao/7WxT2RBTZpOJJdCa4TOUdiLsjTnmKJvzX J4xLvbcyzT4pAfPL7qzw12eK4lacpzZ9uswEjGdzwQv1BHjDP7N2FLvXxbIbXTQX xBqsmTj4d0M6fb5jkHm0Xx37BlAZNy+jTxgN4K1DqNrU2NjB79IyRmUfaGYpNAHK 0W6aJhcATmnoa/Z0fx+ZmwKiGK6fcLfUP+gMw1HPBQpDtx7TfV5uRHN23T0pIDL7 RVN6SLh1AUdxewiol8IXl2lzku8OAtaagGBZSuP9Bvy07+JHmfP5n1AfWVgSMnTG r+rZFaX5nD6cvSSKO1hwJ/dHROc6XPNJ4Dkr+5FXstx+q6Acemv9F2IvfnjiYuyA jbp6pQTKDIjEBAEBCAAuFiEE3Si95tmHXKvOSosd3M8NswvBBUgFAmTVx6oQHGFy bmVfYmFiQHdlYi5kZQAKCRDczw2zC8EFSCfKA/9qXM9yEgxFF94+Rxhg3DYjI+tb EoWu/NoJww1eXjgZl7iosVMv9Si2etPrVcBdEglmrgUO6Tn48huwKNgaF3gTDhCs nfBzxZTHWnKZdCClmMKPnTmnISxmSkDlQsBp6WeE10Yw37sRDr1CCk8CCyk/sZ1M 28cQXZOlmlAIhaXTAQ== =k4tJ -----END PGP SIGNATURE----- --=-=-=--