From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Maxime Devos via "Developers list for Guile, the GNU extensibility library" Newsgroups: gmane.lisp.guile.devel Subject: RE: Exporting a nonexistent variable Date: Thu, 14 Nov 2024 10:42:24 +0100 Message-ID: <20241114104224.cZiN2D00o2o9iX101ZiPo0@xavier.telenet-ops.be> References: Reply-To: Maxime Devos Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_EDB92FFD-2A78-4CDC-82F2-453CA1F9B400_" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30563"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library" To: Attila Lendvai , =?utf-8?Q?Tommi_H=C3=B6yn=C3=A4l=C3=A4nmaa?= Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Thu Nov 14 10:43:00 2024 Return-path: Envelope-to: guile-devel@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 1tBWNO-0007lf-Cw for guile-devel@m.gmane-mx.org; Thu, 14 Nov 2024 10:42:58 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tBWMx-00015p-VX; Thu, 14 Nov 2024 04:42:31 -0500 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 1tBWMw-00015b-VO for guile-devel@gnu.org; Thu, 14 Nov 2024 04:42:31 -0500 Original-Received: from xavier.telenet-ops.be ([2a02:1800:120:4::f00:14]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tBWMu-0007JY-RQ for guile-devel@gnu.org; Thu, 14 Nov 2024 04:42:30 -0500 Original-Received: from [IPv6:2a02:1811:8c0e:ef00:8462:ca35:27c:446a] ([IPv6:2a02:1811:8c0e:ef00:8462:ca35:27c:446a]) by xavier.telenet-ops.be with cmsmtp id cZiN2D00o2o9iX101ZiPo0; Thu, 14 Nov 2024 10:42:24 +0100 Importance: normal X-Priority: 3 In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r24; t=1731577344; bh=WouStW4ENHUgktVtlnV16ofvrGL05MI3Nm7qncoSjW8=; h=Message-ID:MIME-Version:To:Cc:From:Subject:Date:In-Reply-To: References:Content-Type:From; b=A3QW4lC5XgC6eKJdyRFkAFIWZueYsjmcG2yTlfUIaOr6rzX/Nqk1ydE/I5PHBZSx3 lClISWhfRlqWNWzeWNwB5ScMLGiS2QXZrKZMCm/W7byenNEFVzDn07BBaicPHkHSnE OrX29aKG0ltWpgewT8E/sjUB8wOmuSpwbTrZP0LqcSpc+IYNWtnwt3xtaWkmedEh/A VViDYWjb6GNUSJHrWwo2ipEhgEnfAvnsNfnguwFMXtrsZ28ELbXleWr9DTYp8dWL8T wMWphXbWpC5n7VKolcrryoHI9wMgnsiGxhYTlw6uhBPC6ltHpJpYcEAfpuqBDgH06Q tgakUoSCFG1TQ== Received-SPF: pass client-ip=2a02:1800:120:4::f00:14; envelope-from=maximedevos@telenet.be; helo=xavier.telenet-ops.be X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.devel:22774 Archived-At: --_EDB92FFD-2A78-4CDC-82F2-453CA1F9B400_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" (My current e-mail client keeps corrupting guile-devel@gnu.org and refuses = access to the contact list, please ignore wrong address) >there are various use-cases where one wants to export a symbol [sic] from = a module without binding [sic] any value to it in the module where it is be= ing exported from. Symbol -> variable, without binding any value -> without defining it to som= e value, see https://www.gnu.org/software/guile/manual/html_node/Variables= .html. Definedness and boundness are not the same thing. (It=E2=80=99s annoying that after the introduction where it talks about def= inedness / boundness distinction, it gets things wrong again in the first p= rocedure `make-undefined-variable` and later `variable-bound?=E2=80=99.)=20 What use cases would this be? All I can think of is: >(define-module (a) #:export (b) (=3D>)) >(define b) >(define-syntax =3D> [something that makes compile-time error about this ne= eding a syntax-parameterize) In the first case, the variable =E2=80=98b=E2=80=99 is =E2=80=98undefined= =E2=80=99. But it is still bound: an undefined variable is bound the symbol= =E2=80=98b=E2=80=99 In the module =E2=80=98a=E2=80=99. In the second case,= a variable with the name =E2=80=98=3D>=E2=80=99 is defined (and has the st= atus of a macro), but only as a placeholder and except for error messages, = it might as well have been undefined instead. Neither of these is the situation in the original code, where the symbol wa= sn=E2=80=99t bound to any variable =E2=80=93 no corresponding variable exis= ts, whether defined or undefined (unless the =E2=80=98export=E2=80=99 impli= citly creates variables, but that=E2=80=99s rather implicit and undocumente= d). And I don=E2=80=99t see any use case for that. Would be interesting to investigate what RnRS has to say about the situatio= n. > WARNING: (guile-user): `myproc' imported from both (mod1) and (mod2) >this^ is key, never ignore such warnings! i'd go as far as to suggest that= this warning should be turned into an error. that would force the author t= o fix his package definitions to explicitly resolve such collisions. Unless =E2=80=98myproc=E2=80=99 isn=E2=80=99t used (and it=E2=80=99s a whol= e module being compiled at once, not a REPL situation), then the import con= flict wouldn=E2=80=99t matter. Could use a somewhat subtler approach. Best regards, Maxime Devos --_EDB92FFD-2A78-4CDC-82F2-453CA1F9B400_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

(My current e-mail client keeps corrupting guile-devel@gnu.org and refuses access to the cont= act list, please ignore wrong address)

 

<= span lang=3DEN-GB>>there are various use-cases where one wants to export= a symbol [sic] from a module without binding [sic] any value to it in the = module where it is being exported from.

 

= Symbol -> variable, without binding any value -> w= ithout defining it to some value,=C2=A0 see https://www.gnu.org/softwar= e/guile/manual/html_node/Variables.html. Definedness and boundness are = not the same thing.

(It=E2=80=99s annoying that after the introduction where it talks abo= ut definedness / boundness distinction, it gets things wrong again in the f= irst procedure `make-undefined-variable` and later `variable-bound?=E2=80= =99.)

&n= bsp;

What use cases= would this be?

 

All I= can think of is:

 

>= ;(define-module (a) #:export (b) (=3D>))

>(define b)

>(define-syntax =3D> [something that= makes compile-time error about this needing a syntax-parameterize)

 

In the first case, the varia= ble =E2=80=98b=E2=80=99 is =E2=80=98undefined=E2=80=99. But it is still bou= nd: an undefined variable is bound the symbol =E2=80=98b=E2=80=99 In the mo= dule =E2=80=98a=E2=80=99. In the second case, a variable with the name =E2= =80=98=3D>=E2=80=99 is defined (and has the status of a macro), but only= as a placeholder and except for error messages, it might as well have been= undefined instead.

 

N= either of these is the situation in the original code, where the symbol was= n=E2=80=99t bound to any variable =E2=80=93 no corresponding variable exist= s, whether defined or undefined (unless the =E2=80=98export=E2=80=99 implic= itly creates variables, but that=E2=80=99s rather implicit and undocumented= ). And I don=E2=80=99t see any use case for that.

 

Would be interesting to investigate what RnRS = has to say about the situation.

<= span lang=3DEN-GB> 

> WARNING: (guile-user): `myproc' imported from both (mod1) a= nd (mod2)

 

>this^ i= s key, never ignore such warnings! i'd go as far as to suggest that this wa= rning should be turned into an error. that would force the author to fix hi= s package definitions to explicitly resolve such collisions.

 

=

Unless =E2=80=98myproc=E2=80=99 isn= =E2=80=99t used (and it=E2=80=99s a whole module being compiled at once, no= t a REPL situation), then the import conflict wouldn=E2=80=99t matter. Coul= d use a somewhat subtler approach.

 

Best regards,

Maxime Devos

= --_EDB92FFD-2A78-4CDC-82F2-453CA1F9B400_--