From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: lloda Newsgroups: gmane.lisp.guile.bugs Subject: bug#40371: [R7RS] Guile does not accept library name parts that are non-negative exact integers Date: Thu, 2 Apr 2020 22:26:35 +0200 Message-ID: <1D850577-4032-4F3E-B6C7-0D1288FE502A@sarc.name> References: <87369lg132.fsf@igalia.com> Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_02723BF5-5C09-4D5B-9FDA-E95C58FAEE89" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="127723"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Andy Wingo , 40371@debbugs.gnu.org To: Marc =?UTF-8?Q?Nieper-Wi=C3=9Fkirchen?= Original-X-From: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Thu Apr 02 22:27:11 2020 Return-path: Envelope-to: guile-bugs@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 1jK6Qg-000X4M-AV for guile-bugs@m.gmane-mx.org; Thu, 02 Apr 2020 22:27:10 +0200 Original-Received: from localhost ([::1]:47064 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jK6Qf-0006sp-Dp for guile-bugs@m.gmane-mx.org; Thu, 02 Apr 2020 16:27:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43670) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jK6Qa-0006sW-5k for bug-guile@gnu.org; Thu, 02 Apr 2020 16:27:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jK6QY-0006cu-O6 for bug-guile@gnu.org; Thu, 02 Apr 2020 16:27:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57518) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jK6QY-0006ck-KX for bug-guile@gnu.org; Thu, 02 Apr 2020 16:27:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jK6QY-0003K5-Gl for bug-guile@gnu.org; Thu, 02 Apr 2020 16:27:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: lloda Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Thu, 02 Apr 2020 20:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40371 X-GNU-PR-Package: guile Original-Received: via spool by 40371-submit@debbugs.gnu.org id=B40371.158585921212735 (code B ref 40371); Thu, 02 Apr 2020 20:27:02 +0000 Original-Received: (at 40371) by debbugs.gnu.org; 2 Apr 2020 20:26:52 +0000 Original-Received: from localhost ([127.0.0.1]:40831 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jK6QN-0003JJ-EX for submit@debbugs.gnu.org; Thu, 02 Apr 2020 16:26:51 -0400 Original-Received: from mta-08-4.privateemail.com ([198.54.122.58]:27829) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jK6QI-0003Ii-LY for 40371@debbugs.gnu.org; Thu, 02 Apr 2020 16:26:49 -0400 Original-Received: from MTA-08.privateemail.com (localhost [127.0.0.1]) by MTA-08.privateemail.com (Postfix) with ESMTP id E936C60052; Thu, 2 Apr 2020 16:26:38 -0400 (EDT) Original-Received: from [192.168.1.105] (unknown [10.20.151.235]) by MTA-08.privateemail.com (Postfix) with ESMTPA id A12F76005C; Thu, 2 Apr 2020 20:26:37 +0000 (UTC) In-Reply-To: X-Mailer: Apple Mail (2.3445.104.11) X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Original-Sender: "bug-guile" Xref: news.gmane.io gmane.lisp.guile.bugs:9709 Archived-At: --Apple-Mail=_02723BF5-5C09-4D5B-9FDA-E95C58FAEE89 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 (import (srfi 9)) doesn't work, but (import (srfi :9)) does. > On 2 Apr 2020, at 21:47, Marc Nieper-Wi=C3=9Fkirchen = wrote: >=20 >=20 >=20 > Am Do., 2. Apr. 2020 um 21:05 Uhr schrieb Andy Wingo >: > In the concrete case of the SRFI modules, importing e.g. (srfi 9) = works > AFAIU. Does this not work for you? >=20 > I use Guile 3.9.1. >=20 > I can do (import (srfi srfi-9)), but I can't do (import (srfi 9)). >=20 > That latter yields the error: >=20 > source expression failed to match any pattern in form (srfi 9). > =20 >=20 > I think that allowing numbers as module name components, beyond the = SRFI > modules, is not currently a good idea for Guile. I had a look at it = and > it's a bit too intrusive. >=20 > If numbers are not allowed, Guile will be severely crippled with = respect to R7RS code. Most SRFIs are distributed under the name `(srfi = NNN)' so many R7RS programs intended to be portable will try to import = libraries of the form, say `(srfi 9)' and Guile would complain. >=20 > `cond-expand' is not helpful here in general as an R7RS top-level = program has to start with an import and cannot start with some = `(cond-expand (guile ...))'. (Besides, `cond-expand' has its own = problems: = https://lists.gnu.org/archive/html/bug-guile/2020-03/msg00097.html = ). >=20 > As a quick-and-dirty workaround, I would suggest that the Guiles = (syntax-case?) parser of library names accepts numbers as module name = components but treats them internally as symbols (say, by prefixing them = with a colon) so that the main module code doesn't have to be touched. = The locator for library code in the file system will then have to look = for a filenname with a colon and without. >=20 > Marc >=20 > =20 >=20 > Andy >=20 > On Wed 01 Apr 2020 12:47, Marc Nieper-Wi=C3=9Fkirchen = > writes: >=20 > > An R7RS library name consists of parts, where each part is either a = symbol or > > a non-negative exact integer. Guile doesn't support the latter ones. > > > > This is unfortunate as the implementation of a SRFI NNN is usually = delivered > > in form of a library named (srfi NNN). > > > > When this is corrected, for interoperability, it would be great if = Guile offers > > the included SRFIs not only under the name (srfi srfi-NNN) but also = under > > (srfi NNN). > > > > Thanks, > > > > Marc --Apple-Mail=_02723BF5-5C09-4D5B-9FDA-E95C58FAEE89 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

(import (srfi 9)) doesn't work, but = (import (srfi :9)) does.



On 2 Apr = 2020, at 21:47, Marc Nieper-Wi=C3=9Fkirchen <marc.nieper@gmail.com> wrote:



Am Do., 2. Apr. 2020 um 21:05 Uhr schrieb Andy = Wingo <wingo@igalia.com>:
In the concrete case of the = SRFI modules, importing e.g. (srfi 9) works
AFAIU.  Does this not work for you?

I use Guile = 3.9.1.

I can do (import = (srfi srfi-9)), but I can't do (import (srfi 9)).

That latter yields the error:

source expression failed to match any pattern in = form (srfi 9).
 

I think that allowing numbers as module name components, beyond the = SRFI
modules, is not currently a good idea for Guile.  I had a look at = it and
it's a bit too intrusive.

If numbers are not allowed, Guile will be = severely crippled with respect to R7RS code. Most SRFIs are distributed = under the name `(srfi NNN)' so many R7RS programs intended to be = portable will try to import libraries of the form, say `(srfi 9)' and = Guile would complain.

`cond-expand' is = not helpful here in general as an R7RS top-level program has to start = with an import and cannot start with some `(cond-expand (guile ...))'. = (Besides, `cond-expand' has its own problems: https://lists.gnu.org/archive/html/bug-guile/2020-03/msg00097.h= tml).

As a = quick-and-dirty workaround, I would suggest that the Guiles = (syntax-case?) parser of library names accepts numbers as module name = components but treats them internally as symbols (say, by prefixing them = with a colon) so that the main module code doesn't have to be touched. = The locator for library code in the file system will then have to look = for a filenname with a colon and without.

Marc

 

Andy

On Wed 01 Apr 2020 12:47, Marc Nieper-Wi=C3=9Fkirchen <marc.nieper@gmail.com> writes:

> An R7RS library name consists of parts, where each part is either a = symbol or
> a non-negative exact integer. Guile doesn't support the latter = ones.
>
> This is unfortunate as the implementation of a SRFI NNN is usually = delivered
> in form of a library named (srfi NNN).
>
> When this is corrected, for interoperability, it would be great if = Guile offers
> the included SRFIs not only under the name (srfi srfi-NNN) but also = under
> (srfi NNN).
>
> Thanks,
>
> Marc

= --Apple-Mail=_02723BF5-5C09-4D5B-9FDA-E95C58FAEE89--