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.
Thanks for your feedback. Your votes have been recorded. On Mon, 2010-01-11 at 15:30 -0500, R. Kent Dybvig wrote: > > 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. Good points. I've changed my mind, I won't make the change to SRFI 104. If it were changed, because the semantics still will not be portable, there isn't really a benefit. Leaving this aspect of SRFI 104 as it currently is makes it clearer that the affect on library locating of changing the parameters is not portable, whereas if it were changed it would be misleadingly suggesting that the affect is portable. > > 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. Yeah, having the SRFI restrict Windows' path separator to only one out of multiple allowed isn't good. In the recent discussion with Vitaly, I decided to have the explanation of why characters are encoded be the statement about what the path separators are, which will include both of Windows', because that's the only part this issue is relevant to. > 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. What do you suggest for such a mechanism? How will the specification of the set of encoded characters be updated after SRFI 103 is finalized? Perhaps a good, different, way to update the set is by creating a new short SRFI which modifies this one by just saying something like "this SRFI supersedes SRFI 103 and it is everything SRFI 103 is except the set of encoded characters is modified to be ..."? I do agree that a fixed set is not a complete solution for the future or current unpopular OSs, and I certainly want Linux, Mac, Windows, and the entire prevalent OS paradigm to all die and be replaced by better OSs (same for CPUs). -- : Derick ----------------------------------------------------------------