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

Previous Next

To reply to this bug, email your comments to 40371 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Marc Nieper-Wißkirchen <marc.nieper <at> gmail.com>
To: bug-guile <at> gnu.org
Subject: [R7RS] Guile does not accept library name parts that are non-negative
 exact integers
Date: Wed, 1 Apr 2020 12:47:12 +0200

[Message part 1 (text/plain, inline)]

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)]

Message #8 received at 40371 <at> debbugs.gnu.org (full text, mbox):

From: Andy Wingo <wingo <at> igalia.com>
To: Marc Nieper-Wißkirchen <marc.nieper <at> gmail.com>
Cc: 40371 <at> debbugs.gnu.org
Subject: Re: bug#40371: [R7RS] Guile does not accept library name parts that
 are non-negative exact integers
Date: Thu, 02 Apr 2020 21:05:37 +0200

In the concrete case of the SRFI modules, importing e.g. (srfi 9) works
AFAIU.  Does this not work for you?

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 #11 received at 40371 <at> debbugs.gnu.org (full text, mbox):

From: Marc Nieper-Wißkirchen <marc.nieper <at> gmail.com>
To: Andy Wingo <wingo <at> igalia.com>
Cc: 40371 <at> debbugs.gnu.org
Subject: Re: bug#40371: [R7RS] Guile does not accept library name parts that
 are non-negative exact integers
Date: Thu, 2 Apr 2020 21:47:19 +0200

[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?
>

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 <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)]

Message #14 received at 40371 <at> debbugs.gnu.org (full text, mbox):

From: lloda <lloda <at> sarc.name>
To: Marc Nieper-Wißkirchen <marc.nieper <at> gmail.com>
Cc: Andy Wingo <wingo <at> igalia.com>, 40371 <at> debbugs.gnu.org
Subject: Re: 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 part 1 (text/plain, inline)]

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



> On 2 Apr 2020, at 21:47, Marc Nieper-Wißkirchen <marc.nieper <at> gmail.com> wrote:
> 
> 
> 
> Am Do., 2. Apr. 2020 um 21:05 Uhr schrieb Andy Wingo <wingo <at> igalia.com <mailto: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?
> 
> 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 <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 <marc.nieper <at> gmail.com <mailto: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)]

Message #17 received at 40371 <at> debbugs.gnu.org (full text, mbox):

From: Marc Nieper-Wißkirchen <marc.nieper <at> gmail.com>
To: Andy Wingo <wingo <at> igalia.com>
Cc: 40371 <at> debbugs.gnu.org
Subject: Re: bug#40371: [R7RS] Guile does not accept library name parts that
 are non-negative exact integers
Date: Thu, 9 Apr 2020 10:29:33 +0200

[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)]

Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Marc Nieper-Wißkirchen <marc.nieper <at> gmail.com>
To: bug-guile <at> gnu.org
Subject: Re: [R7RS] Guile does not accept library name parts that are
 non-negative exact integers
Date: Mon, 3 Aug 2020 22:24:31 +0200

*bump*

Am Mi., 1. Apr. 2020 um 12:47 Uhr schrieb Marc Nieper-Wißkirchen
<marc.nieper <at> gmail.com>:
>
> 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 #23 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Martin Becze <mjbecze <at> riseup.net>
To: Marc Nieper-Wißkirchen <marc.nieper <at> gmail.com>,
 bug-guile <at> gnu.org
Subject: Re: [R7RS] Guile does not accept library name parts that are
 non-negative exact integers
Date: Wed, 19 Aug 2020 05:16:57 -0500

[Message part 1 (text/plain, inline)]

Here is a patch that makes things usable for srfi's. (import (srfi
NNNN)) will work. It just remove the guard condition that was catching
the Integers. Does anyone know why the guard was there and if it is
really needed?

Martin

On 8/3/20 3:24 PM, Marc Nieper-Wißkirchen wrote:
> *bump*
> 
> Am Mi., 1. Apr. 2020 um 12:47 Uhr schrieb Marc Nieper-Wißkirchen
> <marc.nieper <at> gmail.com>:
>>
>> 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
>>
> 
> 
> 
> 

[0001-Allow-loading-of-libraries-with-the-form-srfi-NNN.patch (text/x-patch, attachment)]

[signature.asc (application/pgp-signature, attachment)]

Message #26 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Dr. Arne Babenhauserheide" <arne_bab <at> web.de>
To: Martin Becze <mjbecze <at> riseup.net>
Cc: 40371 <at> debbugs.gnu.org, bug-guile <at> gnu.org, marc.nieper <at> gmail.com
Subject: Re: bug#40371: [R7RS] Guile does not accept library name parts that
 are non-negative exact integers
Date: Mon, 24 Aug 2020 13:41:45 +0200

[Message part 1 (text/plain, inline)]

Martin Becze <mjbecze <at> riseup.net> writes:

> Here is a patch that makes things usable for srfi's. (import (srfi
> NNNN)) will work. It just remove the guard condition that was catching
> the Integers. Does anyone know why the guard was there and if it is
> really needed?

Thank you for the patch!

I would like to argue in favor of supporting this. It is currently the
only reason why Guile has to use the r6rs testsuite for srfi-197 instead
of the r7rs testsuite.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

[signature.asc (application/pgp-signature, inline)]

Message #32 received at 40371 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Martin Becze <mjbecze <at> riseup.net>
Cc: 40371 <at> debbugs.gnu.org, marc.nieper <at> gmail.com
Subject: Re: bug#40371: [R7RS] Guile does not accept library name parts that
 are non-negative exact integers
Date: Thu, 23 Nov 2023 09:24:37 -0500

Hello,

Martin Becze <mjbecze <at> riseup.net> writes:

> Here is a patch that makes things usable for srfi's. (import (srfi
> NNNN)) will work. It just remove the guard condition that was catching
> the Integers. Does anyone know why the guard was there and if it is
> really needed?

Is still still an issue when working with R7RS .sld libraries?  It's
been possible to use e.g. (import (srfi 64)) since commit 2cca09126,
dated September 2019.  This is handled in (ice-9 r6rs-libraries), so not
generally available, but it is in the context of a define-library
definition.

Let us know if the problem is solved on your side, and if so, let's
close this issue!

-- 
Thanks,
Maxim

Message #35 received at 40371 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Martin Becze <mjbecze <at> riseup.net>
Cc: 40371 <at> debbugs.gnu.org, marc.nieper <at> gmail.com
Subject: Re: bug#40371: [R7RS] Guile does not accept library name parts that
 are non-negative exact integers
Date: Thu, 23 Nov 2023 22:45:57 -0500

Hi,

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:

> Hello,
>
> Martin Becze <mjbecze <at> riseup.net> writes:
>
>> Here is a patch that makes things usable for srfi's. (import (srfi
>> NNNN)) will work. It just remove the guard condition that was catching
>> the Integers. Does anyone know why the guard was there and if it is
>> really needed?
>
> Is still still an issue when working with R7RS .sld libraries?  It's
> been possible to use e.g. (import (srfi 64)) since commit 2cca09126,
> dated September 2019.  This is handled in (ice-9 r6rs-libraries), so not
> generally available, but it is in the context of a define-library
> definition.
>
> Let us know if the problem is solved on your side, and if so, let's
> close this issue!

I now understand it works in a very limited way.  For example, (srfi 64)
works, but (srfi 160 u8) doesn't, and if someone came up with any other
valid R7RS module name such as (anything 9) it would not work.  The
current support is done at r6rs-libraries.scm (which is kind of the
wrong place to do it as well).

I think there is value addressing it in the core resolve-interface to
better support R7RS libraries.

-- 
Thanks,
Maxim

Message #38 received at 40371 <at> debbugs.gnu.org (full text, mbox):

From: Retropikzel <retropikzel_ <at> disroot.org>
To: 40371 <at> debbugs.gnu.org
Subject: Re: bug#40371: [R7RS] Guile does not accept library name parts that, 
 are non-negative exact integers
Date: Wed, 21 Aug 2024 10:44:05 +0300

I think I ran into this issue in a different place.


Guile does not support the ((library (foo bar) ...) form in cond-expand, 
so one way around it is to have (cond-expand (srfi-N ... ) ((library 
(srfi N)) ...) but in a situation where srfi-N is false Guile tries to 
evaluate the (library ... form and errors with (in the case of N being 180):

In procedure symbol->string: Wrong type argument in position 1 
(expecting symbol): 180


Here is the example code:

(import (scheme base)
        (scheme write))

(cond-expand
  (srfi-180
    (display "I has SRFI 180 :)")
    (newline))
  ((library (srfi 180))
    (display "I has SRFI 180 :)")
    (newline))
  (else
    (display "I do not has SRFI 180 :(")
    (newline)))

It also errors without the number there, saying (switching 180 -> foo):

no code for module (srfi foo)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.