>>  > 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.

>For the time being, (library ...) is only available in R6RS

implementations. But the next report (tentatively titled R7RS-large) is

on track to be a merger of R6RS and R7RS, and hence will most likely

support both (library ...) and (define-library ...) while merging their

semantics in some way.

This is not _yet_ the case – AFAIK R7RS-large is still in progress. So, too soon to implement it for ‘library’ yet – ‘library’ is currently R6RS.

>I would agree that interop between strict R6RS and other dialects of

Scheme is important.

> To that end, the option to use numbers in R6RS

library names using the : prefix is good to have. (R6RS does not have

the vertical bar notation |123| to turn numbers into symbols, so strict

R6RS code cannot even rely on that notation to encode numerical library

name parts).

In the case of SRFI, yes, since that’s what the relevant SRFI says the module names are, but you are formulating this much more generally.

>A further complication is that :123 is a keyword in some Scheme

implementations. (This syntax comes from Common Lisp and Emacs Lisp,

perhaps going as far back as Maclisp.) It might be best if any leading

colon in a library name part is simply removed.

Guile isn’t one of those, so it’s not a problem. As I understand it, (a priori) (foo N), (foo :N) and (foo |N|) are three different module names, so this removal is simply incorrect (barring changes to RnRS). As such leading colons should be kept.

As part of a ‘module name -> file name’ mapping it seems a reasonable choice, but that’s a different matter.

(Not claiming that an implementation should in general support different (foo :N) (foo N) (foo |N|) modules, only that it should recognise them as different names.)

>> [...]

>Guile should support non-negative integers in any library name, not only

for the SRFI libraries. R7RS allows them anywhere.

I never claimed it should be restricted to SRFI libraries. My comment was about the colon and the problems it would cause (more precisely, the lack of problems) (and about not doing it for R6RS library forms).

>I would recommend implementing the %-encoding of arbitrary UTF-8 bytes

(several Scheme implementations do it when translating library names to

file names) but to avoid using it in practice.

Err, no, I recommend _not_ doing that. Unicode brought us the option to be able to just type characters without special tricks, I don’t want Guile to regress to ASCII here.

Now, if Guile were to support both %-encoding (e.g. for : on Windows situations) but also supported (and preferred) just literally including the actual character in the filename (Unicode as intended, applied to file names), that would be fine, but since Guile’s current module implementation just directly maps module names to file names (+ search path), that’s currently not an option (start-up performance implications).  (I don’t think this is an unsurmountable problem, but it does require some reorganization in how Guile libraries are packaged and how Guile searches for .go/.scm.)

(Other option: %-encode only disallowed characters so there is a unique corresponding file name (modulo search paths), but which characters are disallowed depend on file system and OS, so that’s not practical.)

>The : prefixes should be stripped before encoding a library name as a

file name.

>FAT, NTFS (and probably other file systems) do not allow colons in file

names. I am not aware of any file system that forbids the percent sign.

NTFS supports colons just fine(*), it’s Windows that places restrictions on file names.

So, some change is indeed necessary (but not necessarily just always stripping the :, other options exist as well.)

(*) not completely sure – ‘:’ can refer to alternate data streams, but I don’t know whether that’s an NTFS or a Windows thing

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

>> bar) in Guile.

>

>Percent-encoding the slash solves this easily.

See above for how percent-encoding is a problem of its own.

Best regards,

Maxime Devos