* bug#40371: [R7RS] Guile does not accept library name parts that are non-negative exact integers @ 2020-04-01 10:47 Marc Nieper-Wißkirchen 2020-04-02 19:05 ` Andy Wingo 2020-08-03 20:24 ` Marc Nieper-Wißkirchen 0 siblings, 2 replies; 10+ messages in thread From: Marc Nieper-Wißkirchen @ 2020-04-01 10:47 UTC (permalink / raw) To: 40371 [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#40371: [R7RS] Guile does not accept library name parts that are non-negative exact integers 2020-04-01 10:47 bug#40371: [R7RS] Guile does not accept library name parts that are non-negative exact integers Marc Nieper-Wißkirchen @ 2020-04-02 19:05 ` Andy Wingo 2020-04-02 19:47 ` Marc Nieper-Wißkirchen 2020-04-09 8:29 ` Marc Nieper-Wißkirchen 2020-08-03 20:24 ` Marc Nieper-Wißkirchen 1 sibling, 2 replies; 10+ messages in thread From: Andy Wingo @ 2020-04-02 19:05 UTC (permalink / raw) To: Marc Nieper-Wißkirchen; +Cc: 40371 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#40371: [R7RS] Guile does not accept library name parts that are non-negative exact integers 2020-04-02 19:05 ` Andy Wingo @ 2020-04-02 19:47 ` Marc Nieper-Wißkirchen 2020-04-02 20:26 ` lloda 2020-04-09 8:29 ` Marc Nieper-Wißkirchen 1 sibling, 1 reply; 10+ messages in thread From: Marc Nieper-Wißkirchen @ 2020-04-02 19:47 UTC (permalink / raw) To: Andy Wingo; +Cc: 40371 [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#40371: [R7RS] Guile does not accept library name parts that are non-negative exact integers 2020-04-02 19:47 ` Marc Nieper-Wißkirchen @ 2020-04-02 20:26 ` lloda 0 siblings, 0 replies; 10+ messages in thread From: lloda @ 2020-04-02 20:26 UTC (permalink / raw) To: Marc Nieper-Wißkirchen; +Cc: Andy Wingo, 40371 [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#40371: [R7RS] Guile does not accept library name parts that are non-negative exact integers 2020-04-02 19:05 ` Andy Wingo 2020-04-02 19:47 ` Marc Nieper-Wißkirchen @ 2020-04-09 8:29 ` Marc Nieper-Wißkirchen 1 sibling, 0 replies; 10+ messages in thread From: Marc Nieper-Wißkirchen @ 2020-04-09 8:29 UTC (permalink / raw) To: Andy Wingo; +Cc: 40371 [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#40371: [R7RS] Guile does not accept library name parts that are non-negative exact integers 2020-04-01 10:47 bug#40371: [R7RS] Guile does not accept library name parts that are non-negative exact integers Marc Nieper-Wißkirchen 2020-04-02 19:05 ` Andy Wingo @ 2020-08-03 20:24 ` Marc Nieper-Wißkirchen 2020-08-19 10:16 ` Martin Becze 1 sibling, 1 reply; 10+ messages in thread From: Marc Nieper-Wißkirchen @ 2020-08-03 20:24 UTC (permalink / raw) To: 40371 *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 > ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#40371: [R7RS] Guile does not accept library name parts that are non-negative exact integers 2020-08-03 20:24 ` Marc Nieper-Wißkirchen @ 2020-08-19 10:16 ` Martin Becze 2020-08-24 11:41 ` Dr. Arne Babenhauserheide 2023-11-23 14:24 ` Maxim Cournoyer 0 siblings, 2 replies; 10+ messages in thread From: Martin Becze @ 2020-08-19 10:16 UTC (permalink / raw) To: marc.nieper, 40371 [-- 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 --] ^ permalink raw reply related [flat|nested] 10+ messages in thread
* bug#40371: [R7RS] Guile does not accept library name parts that are non-negative exact integers 2020-08-19 10:16 ` Martin Becze @ 2020-08-24 11:41 ` Dr. Arne Babenhauserheide 2023-11-23 14:24 ` Maxim Cournoyer 1 sibling, 0 replies; 10+ messages in thread From: Dr. Arne Babenhauserheide @ 2020-08-24 11:41 UTC (permalink / raw) To: Martin Becze; +Cc: 40371, marc.nieper [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#40371: [R7RS] Guile does not accept library name parts that are non-negative exact integers 2020-08-19 10:16 ` Martin Becze 2020-08-24 11:41 ` Dr. Arne Babenhauserheide @ 2023-11-23 14:24 ` Maxim Cournoyer 2023-11-24 3:45 ` Maxim Cournoyer 1 sibling, 1 reply; 10+ messages in thread From: Maxim Cournoyer @ 2023-11-23 14:24 UTC (permalink / raw) To: Martin Becze; +Cc: 40371, marc.nieper 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#40371: [R7RS] Guile does not accept library name parts that are non-negative exact integers 2023-11-23 14:24 ` Maxim Cournoyer @ 2023-11-24 3:45 ` Maxim Cournoyer 0 siblings, 0 replies; 10+ messages in thread From: Maxim Cournoyer @ 2023-11-24 3:45 UTC (permalink / raw) To: Martin Becze; +Cc: 40371, marc.nieper 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2023-11-24 3:45 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-04-01 10:47 bug#40371: [R7RS] Guile does not accept library name parts that are non-negative exact integers Marc Nieper-Wißkirchen 2020-04-02 19:05 ` Andy Wingo 2020-04-02 19:47 ` Marc Nieper-Wißkirchen 2020-04-02 20:26 ` lloda 2020-04-09 8:29 ` Marc Nieper-Wißkirchen 2020-08-03 20:24 ` Marc Nieper-Wißkirchen 2020-08-19 10:16 ` Martin Becze 2020-08-24 11:41 ` Dr. Arne Babenhauserheide 2023-11-23 14:24 ` Maxim Cournoyer 2023-11-24 3:45 ` Maxim Cournoyer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).