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