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.
Derick Eddington wrote: > --------------------------- > Changes I'm undecided about > --------------------------- > > 1) [...] instead of (foo) use (foo main) Please don't. If I develop (foo) in a separate directory, I do not want it to suddenly become (foo main). This would be syntactic clutter I would not forgive as an end user. > 2) [...] (a%/b c:*d) would map to the file name "a%25%%2F%b/c%3A%%2A%d.ext", > instead of "a%25%2Fb/c%3A%2Ad.ext" [...] URI encoding gives a well known precedent, no need to break it. > ------------------------------------- > Changes I assume aren't controversial > ------------------------------------- > [...] > 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. You need the element separator to extract the path list, so it should be defined. Path separator on the other hand is something you don't care about beyond constructing sub-paths -- a process invisible to the user, so you don't need to define them beyond "recognizable by the OS". > 7) Add #\; to the set of encoded characters, because a directory could be both > in the SCHEME_LIB_PATH sequence and correspond to a library name component. > Such a directory with a name including #\; is unusual but must be supported, > otherwise an unencoded #\; would be misinterpreted in SCHEME_LIB_PATH. I heard that when you strive to fail safety it's best to enumerate allowed things, not the forbidden ones. How about "Encode everything except for [a-zA-Z0-9_.-]"? It's safe, short, simple and works for 99% of libraries without any encoding at all.