bug#40371: [R7RS] Guile does not accept library name parts that are non-negative exact integers

Marc Nieper-Wißkirchen <[email protected]>
Newsgroups gmane.lisp.guile.bugs
Message-ID <CAEYrNrQj97ZN215oXjaxgWYyVYO4zVuZqW-xhMbp0UvpNwBybA@mail.gmail.com>
Am Do., 2. Apr. 2020 um 21:05 Uhr schrieb Andy Wingo <[email protected]>:

> 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.html).

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ßkirchen <[email protected]>
> 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
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.