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

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

[Marc Nieper-Wißkirchen]

[-- Attachment #1: Type: text/plain, Size: 446 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1114 bytes --]

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

[Andy Wingo]

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@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

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

[Marc Nieper-Wißkirchen]

[-- Attachment #1: Type: text/plain, Size: 2169 bytes --]

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.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@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
>

[-- Attachment #2: Type: text/html, Size: 3881 bytes --]

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

[lloda]

[-- Attachment #1: Type: text/plain, Size: 2471 bytes --]


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



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


[-- Attachment #2: Type: text/html, Size: 4986 bytes --]

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

[Marc Nieper-Wißkirchen]

[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]

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

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@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
>

[-- Attachment #2: Type: text/html, Size: 2722 bytes --]

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

[Marc Nieper-Wißkirchen]

*bump*

Am Mi., 1. Apr. 2020 um 12:47 Uhr schrieb Marc Nieper-Wißkirchen
<marc.nieper@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
>

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

[Martin Becze]

[-- Attachment #1.1.1: Type: text/plain, Size: 901 bytes --]

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@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
>>
> 
> 
> 
> 

[-- Attachment #1.1.2: 0001-Allow-loading-of-libraries-with-the-form-srfi-NNN.patch --]
[-- Type: text/x-patch, Size: 1028 bytes --]

From d5518a32d4ed05fccd1e81c1596a77ae74d0136c Mon Sep 17 00:00:00 2001
From: Martin Becze <mjbecze@riseup.net>
Date: Wed, 19 Aug 2020 05:00:54 -0500
Subject: [PATCH] Allow loading of libraries with the form (srfi NNN).

* module/ice-9/r6rs-libraries.scm: Removed guard condition that was
filtering out intergers.
---
 module/ice-9/r6rs-libraries.scm | 2 --
 1 file changed, 2 deletions(-)

diff --git a/module/ice-9/r6rs-libraries.scm b/module/ice-9/r6rs-libraries.scm
index c6ba6a496..0eee5fb7e 100644
--- a/module/ice-9/r6rs-libraries.scm
+++ b/module/ice-9/r6rs-libraries.scm
@@ -152,11 +152,9 @@
              (lp (cdr in) (cons (vector to replace? var) out))))))))
     
     ((name name* ... (version ...))
-     (and-map sym? #'(name name* ...))
      (resolve-r6rs-interface #'(library (name name* ... (version ...)))))
 
     ((name name* ...) 
-     (and-map sym? #'(name name* ...))
      (resolve-r6rs-interface #'(library (name name* ... ()))))))
 
 (define-syntax library
-- 
2.28.0


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 567 bytes --]


Martin Becze <mjbecze@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1076 bytes --]

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

[Maxim Cournoyer]

Hello,

Martin Becze <mjbecze@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

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

[Maxim Cournoyer]

Hi,

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

> Hello,
>
> Martin Becze <mjbecze@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

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

[Retropikzel via Bug reports for GUILE, GNU's Ubiquitous Extension Language]

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)