unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
* 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; 8+ 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] 8+ 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; 8+ 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] 8+ 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; 8+ 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] 8+ 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; 8+ 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] 8+ 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; 8+ 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] 8+ 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; 8+ 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] 8+ 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
  0 siblings, 1 reply; 8+ 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	[flat|nested] 8+ 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
  0 siblings, 0 replies; 8+ 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] 8+ messages in thread

end of thread, other threads:[~2020-08-24 11:41 UTC | newest]

Thread overview: 8+ 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

unofficial mirror of bug-guile@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/guile-bugs/0 guile-bugs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 guile-bugs guile-bugs/ https://yhetil.org/guile-bugs \
		bug-guile@gnu.org
	public-inbox-index guile-bugs

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.lisp.guile.bugs
	nntp://news.gmane.io/gmane.lisp.guile.bugs


AGPL code for this site: git clone http://ou63pmih66umazou.onion/public-inbox.git