This page is part of the web mail archives of SRFI 103 from before July 7th, 2015. The new archives for SRFI 103 contain all messages, not just those from before July 7th, 2015.
> In conclusion, I don't see why considering library names as > representations of contemporary file names is proper, and I don't see > why it outweighs the importance of abstract unrestricted library names. All of what you say follows from your perspective but is uncompelling to me from my perspective. So perhaps we just have to agree to disagree. But in your second-to-last paragraph: > If you want to override the SRFI to catch such library names, you can > also map them to a file name without the SRFI's encoding (maybe just the > "absolute path" first symbol). Same for ~. lies a possible compromise I might be able to justify implementing: require a system to look first for the unencoded version of the constructed pathname (ignoring search-path prefixes if the pathname is absolute in the host filesystem) and, if that fails, then for the encoded version. For example, say the list of library directories includes "lib1" and "lib2" and the list of library extensions includes only "sls". Then the system looks for (/ foo) first in /foo.sls, then in lib1/%2f%/foo.sls, then in lib2/%2f%/foo.sls. It looks for (srfi :1) first in lib1/srfi/:1.sls, then in lib2/srfi/:1.sls, then in lib1/srfi/%3a%1.sls, then in lib2/srfi/%3a%1.sls. This should allow one to name any file that exists in the filesystem and to specify absolute pathnames for convenience or security, without inhibiting the sharing of filenames with funny characters via the %scalar-value% encoding. Obviously, a system could choose not to bother trying the unencoded version of the path name if it is clearly not valid for the underlying filesystem. Incidentally, is there a reason to chose "r6rs-lib" as the extension for R6RS libraries rather than the shorter "sls" as recommended in the R6RS non-normative appendices? We selected sls because it did not (to our knowledge) conflict with existing extensions for Scheme source code, so I assume that's not your reason. If there is no particular reason why you chose r6rs-lib, please change it to sls. Also, Chez Scheme treats a trailing separator character (":" under Unix-based systems, ";" under Windows) in its variants of SCHEME_LIB_PATH and SCHEME_LIB_EXTENSIONS as an indication that the system should look in the system-specific libraries/extensions if the library isn't found in the user-specified set. (This mirrors similar behavior for the LD_LIBRARY_PATH variable used by some Unix dynamic loaders.) Perhaps SRFI 103 should do the same. For example, if SCHEME_LIB_PATH is set to "foo:bar" on a Unix-based system, the system should look in foo and bar only, but if SCHEME_LIB_PATH is set to "foo:bar:", the system should look in foo, bar, and any system-specific library directories. It is useful to prevent the system from looking in system-specific libraries if you want to make sure you know exactly where each library is coming from, and it is useful for user directories to be searched first if you have a library you want used in preference to one shipped with the implementation. Kent