[-- 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 --]
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
[-- 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 --]
[-- 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 --]
[-- 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 --]
*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.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 --]
[-- 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 --]
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
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