>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
