>In R7RS non-negative integers can be library name parts. Since these

library names look natural, it would be good to backport this to R6RS

implementations.

Then (library [...] (import (srfi 1)) [...]) would work, and since ‘library’ is (R6RS) standard and reasonably portable it would then appear that (srfi 1) is (R6RS) standard and portable, whereas it isn’t R6RS, and hence not a good idea to backport.

>The colon causes endless grief when mapping library names to file names.

>For example, look at all the %3a in

https://github.com/arcfide/chez-srfi. That's not even the worst of it.

I don’t think this is a problem for Guile? I don’t recall to what extent, but (srfi ...) modules are somewhat special-cased in Guile (or maybe it was integers in general for define-library) – maybe its implementation of define-library translates (srfi 1) to (srfi srfi-1) (I don’t recall the specifics). Hence, the file can simply be named “srfi/srfi-1.scm”.

For compatibility, both(**) (srfi srfi-N) (ß non-standard Guile thingie) and (srfi :N) need to be supported anyway for ‘define-module’ (ß Guile-specific interface), so which of them determines the file name is just a matter of convenience.

Also, AFAIK that %3a encoding isn’t necessary (and neither recognised(^)) in Guile – I don’t think Guile does any percent encoding(*). I think naming the file “srfi/:1.scm” would work fine, although it’s not something I’ve tried before. (There might be a problem with Makefile if ‘make’ doesn’t like the :, but I have some ideas for simple ways around that.)

(*) implication: you can’t have two different modules (foo/bar) and (foo bar) in Guile.

(^) (srfi %3a1) would mean the module has literally (srfi %3a1) as name.

(**) not entirely true, only supporting (srfi srfi-N) (in define-module) would be compatible, but that does not seem to be the future.

Best regards,

Maxime Devos