GNU bug report logs -
#40371
[R7RS] Guile does not accept library name parts that are non-negative exact integers
Previous Next
Full log
Message #17 received at 40371 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Am Do., 2. Apr. 2020 um 21:05 Uhr schrieb Andy Wingo <wingo <at> igalia.com>:
> In the concrete case of the SRFI modules, importing e.g. (srfi 9) works
> AFAIU. Does this not work for you?
>
In this clause, it is checked whether every part of the library's name is a
symbol:
http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=module/ice-9/r6rs-libraries.scm;h=c6ba6a4964d1eb861ef7eca1076d5e7019c134c4;hb=HEAD#l158
Interestingly, the long library form `(library (srfi srfi-9))' doesn't work
either here because `library' is not recognized as a keyword but mistaken
as the name for a library.
Marc
>
> 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.
>
> Andy
>
> On Wed 01 Apr 2020 12:47, Marc Nieper-Wißkirchen <marc.nieper <at> 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
>
[Message part 2 (text/html, inline)]
This bug report was last modified 297 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.