From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Marc_Nieper=2DWi=C3=9Fkirchen?= Newsgroups: gmane.lisp.guile.devel Subject: Re: Are library names data or syntax? Date: Tue, 23 Jul 2024 16:42:57 +0200 Message-ID: References: <20240722204721.qinL2C00T2kuPDg01inMky@xavier.telenet-ops.be> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000027c2c6061deb2ec2" Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11878"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Taylan Kammer , "guile-devel@gnu.org" , Lassi Kortela , Arne Babenhauserheide To: Maxime Devos Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Tue Jul 23 16:43:28 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 1sWGjf-0002tE-Ug for guile-devel@m.gmane-mx.org; Tue, 23 Jul 2024 16:43:28 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sWGjU-0005ee-Ud; Tue, 23 Jul 2024 10:43:16 -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 1sWGjT-0005dE-8Y for guile-devel@gnu.org; Tue, 23 Jul 2024 10:43:15 -0400 Original-Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.163]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sWGjQ-0004Bo-Pn for guile-devel@gnu.org; Tue, 23 Jul 2024 10:43:15 -0400 ARC-Seal: i=1; a=rsa-sha256; t=1721745790; cv=none; d=strato.com; s=strato-dkim-0002; b=VZnZzf9fmOepen8kuA5PUy2AM26IxE6Mh1YdXgiCrHgfftf844omE5x6BhlvZtyMvM y6n2bjrNoKupoZd52Lm1d7HYtnqsOXvWQ8ZIqaFgwkn1r/8/aVRcwi7j0DtnISQWJZM3 OC4XDUhzD1XOH0fEarOyCjh0DgOZTLecKIDXQMlarDOrpcVCAByyvakQ+42wecftRfmX ENHOz+VAOiJHt/pKHGWFQnrjVP6z8SxUsCd/BCtiZ194hNn4UEmXfsG/krws83L7Nj5e reEWPSXFf51WB67GXLFs6HxfRYYcaBrhU3jb6kmU7CwphT3vOa+ad8vuucdt1h7BKgzv juxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1721745790; s=strato-dkim-0002; d=strato.com; h=Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:Cc:Date: From:Subject:Sender; bh=aGpMarxM08Aiznh3SCQXAcvy9bMUCRSQfalj4eTZTDM=; b=hbFJiNRkhO9FdGk4Jl0u7nl6vkET++5ZZzaRo0C0J/6xcXBSlR6knqLM6DnF2ilzeV JrJsty/Ydu5clO9E8g7Z8qOAb1XibHpYU0vqFs1VOP8rB82NNJSVxZJa1/Hoj09VtkCi HTwJrHDwohxw3lmYGOxBcYkOa8jAomrGQIJhvnSKCUiz3aNQhEu3xXvJBfNg1IHsrbyH GVbVnYbitAleKuOUaUf1QqNX/Vjg5K1fRRuqt1rdQxJHtpFI+EfUM4SLtkcHhUT16Sxd CuKj6vuguaVPwjfYgzIK/IeENdT0hSof1w/UN15lOGHXvaewgcR4XYNksubMUogkaY2T N4Yg== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1721745790; s=strato-dkim-0002; d=nieper-wisskirchen.de; h=Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:Cc:Date: From:Subject:Sender; bh=aGpMarxM08Aiznh3SCQXAcvy9bMUCRSQfalj4eTZTDM=; b=lzEnTnht3tI70TjKA8AGhdQ3tzQCitaLIlJoIyGxcpWebbPooIikh9RXDfgp61oGA9 Oa8UkDPOwAqVzJw07KcQGhNPNyaoWTjdiuQWI+Zy/3tvmCov+Hui307JNEh15kJT74yf 1leCUSQNund+d3RMDBAWrBHYAbb2BjFZF6XTBHbpqhIaOH/JV9rkBda7bW0UJjKhLZYN 8UweIlqpe3NWabEsBDydyBesTTkiZswZ/v/vL3TYQ8VDUWgfv8oCLeo0LU5rbsc2ia1j GD7FrYj/cHABh4qlBPjmA2jwYq1ZOO7Db76gCgtS+cGfzXckGU4rVO0r4tmWglcXxDEk TCQQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1721745790; s=strato-dkim-0003; d=nieper-wisskirchen.de; h=Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:Cc:Date: From:Subject:Sender; bh=aGpMarxM08Aiznh3SCQXAcvy9bMUCRSQfalj4eTZTDM=; b=3IyKxi/+/8eGSAx+p8vwVmyt/5tD2p2TXA45Buf/en/P7tDYNuntz0rzyOzE3xxupQ fVCybbGsgN5S1hULH8Dg== X-RZG-AUTH: ":IW0WdmCmcvpIrP2+VJuPtIhjJvc4Ig+QdhX22iZVwSDOx4Kp3cYsBVGy6CZgmO/guIaKVsJ57peB" Original-Received: from mail-ed1-f42.google.com by smtp.strato.de (RZmta 51.1.0 AUTH) with ESMTPSA id nba51506NEh9472 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate) for ; Tue, 23 Jul 2024 16:43:09 +0200 (CEST) Original-Received: by mail-ed1-f42.google.com with SMTP id 4fb4d7f45d1cf-5a156557029so4976715a12.2 for ; Tue, 23 Jul 2024 07:43:09 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCUuImKp4f3Xulwl1exVj58Wp79cR+ZKc7hSyhfJb+QwkQq3KbRDSvFDpJzv81hM79ypbU/mWagtjUQ7pTEcMWiUppqk X-Gm-Message-State: AOJu0YwMl3pPwEoR0x/rXwiap1Cj85vYIDyJO+4+7S/YaQZhigc2SF+6 sfVdplJI1QjY3gcf6WdBv/tzpYYDqDbZ6y6k4USloVYSMK2xY/9HMMx9Yay2Yig4UFSNsDtIPBh wnlZnASN6zBUOq7t5o0SASU3GTSI= X-Google-Smtp-Source: AGHT+IGtRELWq36qIxkPN4rrlPvAIAXCMJ9pQLJpv7kLqa4YZclaS+/nt+CLRhC4qbdNCyTppHf351G2RPDQ2TiIyIw= X-Received: by 2002:a17:907:7d92:b0:a7a:a3f7:38a1 with SMTP id a640c23a62f3a-a7aa3f73a31mr79625166b.29.1721745789137; Tue, 23 Jul 2024 07:43:09 -0700 (PDT) In-Reply-To: <20240722204721.qinL2C00T2kuPDg01inMky@xavier.telenet-ops.be> X-Gmail-Original-Message-ID: Received-SPF: none client-ip=81.169.146.163; envelope-from=marc@nieper-wisskirchen.de; helo=mo4-p00-ob.smtp.rzone.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_NONE=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:22646 Archived-At: --00000000000027c2c6061deb2ec2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Am Mo., 22. Juli 2024 um 20:47 Uhr schrieb Maxime Devos < maximedevos@telenet.be>: > > [...] > > > > > >In what kind of situation might a library name be made up of identifiers > (syntax objects) that might need to carry lexical information? > > > > As implied by the previous: never (in Guile, and probably most others). > > > > The only exception I can think of, is if: > > > > * =E2=80=98define-library=E2=80=99/=E2=80=99library=E2=80=99 is implement= ed as a macro (this is not part > of RnRS, but AFAIK neither is it against the standard) > > * hence, you can define a module from within another module (might be > situationally useful, but comes with new difficulties for module lookup) > > * there are multiple module namespaces > > * to determine which module namespace to put the module in, > =E2=80=98define-library=E2=80=99 uses lexical information > > * in particular, it uses components of the name of the library for lexica= l > information, even though there are other options like using the _*whole*_ > name (i.e., (foo bar) itself instead of =E2=80=98foo=E2=80=99 or =E2=80= =98bar=E2=80=99). > > > > That=E2=80=99s a lot of ifs, and even then identifiers aren=E2=80=99t nec= essary, since > (AFAIK) the name (foo bar) itself carries lexical information (not sure). > > > > I=E2=80=99ve been assuming that numbers (in syntax) (say, #'3) don=E2=80= =99t carry lexical > info, but since =E2=80=98syntax numbers=E2=80=99 carry file name+position= information, it=E2=80=99s > not much of a stretch to potentially also include lexical information, so > perhaps numbers would work just fine too! (Implementation-dependent, but > =E2=80=98multiple module namespaces=E2=80=99 and =E2=80=98define-library = as a macro=E2=80=99 are also > implementation-dependent.) > This would need a redefinition of what a syntax object is (see the R6RS). In principle, this would be possible, but the result would be incompatible with the R6RS. In R6RS, a macro transformer is allowed to output raw numbers; this would not be allowed in a hypothetical Scheme version that assumes that numbers necessarily carry a wrap (as identifiers do in the R6RS). Source location information is not mandatory information for the expander, so this reasoning does not apply here. Marc --00000000000027c2c6061deb2ec2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Am Mo., 22. Juli 2024 um 20:47=C2=A0Uhr schrieb Maxime Devos <maximedevos@telenet.be>:
<= /div>

<= span lang=3D"en-BE">> [...]

>=C2=A0

>In what kind of situation might a library n= ame be made up of identifiers (syntax objects) that might need to carry lex= ical information?

=C2=A0

As implied by the previous: never (in Guile, and probably most o= thers).

=C2=A0

The only exception I can think of, is if:

=C2=A0

* =E2=80=98define-library=E2=80=99/=E2= =80=99library=E2=80=99 is implemented as a macro (this is not part of RnRS,= but AFAIK neither is it against the standard)

* hence, you can define a module fr= om within another module (might be situationally useful, but comes with new= difficulties for module lookup)

* there are multiple module namespaces<= /u>

* to determine wh= ich module namespace to put the module in, =E2=80=98define-library=E2=80=99= uses lexical information

* in particular, it uses components of the name of the l= ibrary for lexical information, even though there are other options like us= ing the _whole_ name (i.e., (foo bar) itself instead of =E2=80=98foo= =E2=80=99 or =E2=80=98bar=E2=80=99).

=C2=A0

That=E2=80=99s a lot of ifs, and even then id= entifiers aren=E2=80=99t necessary, since (AFAIK) the name (foo bar) itself= carries lexical information (not sure).

=C2=A0

I=E2=80=99ve been assuming that numbers= (in syntax) (say, #'3) don=E2=80=99t carry lexical info, but since =E2= =80=98syntax numbers=E2=80=99 carry file name+position information, it=E2= =80=99s not much of a stretch to potentially also include lexical informati= on, so perhaps numbers would work just fine too! (Implementation-dependent,= but =E2=80=98multiple module namespaces=E2=80=99 and =E2=80=98define-libra= ry as a macro=E2=80=99 are also implementation-dependent.)

=

This would need a redefinition of what a syn= tax object is (see the R6RS). In principle, this would be possible, but the= result would be incompatible with the R6RS. In R6RS, a macro transformer i= s allowed to output raw numbers; this would not be allowed in a hypothetica= l Scheme version that assumes that numbers necessarily carry a wrap (as ide= ntifiers do in the R6RS).

Source location information is not mandatory information for= the expander, so this reasoning does not apply here.

Marc

--00000000000027c2c6061deb2ec2--