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.
> 1) Should the implicit file name support be removed? Yes. It complicates the design and the implementation, and it forces programmers to remember (or look up) and deal with special rules for mapping library names to file names. Special cases like this also complicate program-generating programs. If there are tools that make it significantly harder to deal with a foo directory by itself than foo.sls and foo together, I'm fortunate not to have to deal with them, and if there are, it's not too much to ask programmers to import (foo main) instead of (foo). Programmers might rather do that than deal with special cases or have to look in twice as many places when they want to look at a library's source code. Extra bells and whistles can be useful, but so are simplicity and regularity. > 2) Should the character encoding design be changed to encoding of code points > (instead of UTF-8)? I don't feel strongly about this, but I agree with you that: > the terminating character makes it obvious where a character encoding > ends; it's marginally easier to convert characters to and from code points > than to and from UTF-8 encodings; and it is more consistent with Scheme's > syntax for symbols and strings. I couldn't have put it better myself. > 3) I'm thinking SRFI 104 should be changed such that it's required to always > affect library locating, so that there's a portable cross-system interface to > reconfiguring library locating. I don't care one way or another, but I wonder how useful it will be in practice to have such a requirement. Even if this were intended to support only R6RS systems, the semantics will not be clear because of the control implementations have over when and whether libraries are loaded, visited, and invoked, and in systems that separate phases, there's always the question about whether setting the parameter in one phase will have any impact on the loading of libraries in another. > 6) Define the pathname component separator character to be #\/ on Unixes and #\\ > on Windows. Define the environment variable element separator character to be > #\: on Unixes and #\; on Windows. The current draft is already tied to Unixes > and Windows. Most if not all Windows path-manipulation functions permit #\// to be used as well as #\\, so I would say that either might be used under Windows. Incidentally, I dislike tying a SRFI, which is a standard of sorts, to a particular set of operating systems, even if they are the most popular. It makes the SRFI less general, and from a global perspective, it helps in a small way to perpetuate the popular operating systems to the detriment of other, possibly better options. I would feel better if there were some mechanism for extending the set of encoded characters as new constraints are discovered. This means the correct pathname for a given library name might change at some point, but only if it is found to be unusable in some environment. Kent