On Wed, 2010-01-27 at 15:58 -0500, R. Kent Dybvig wrote:
> > Why do you suppose C has never specified any mapping between #include <>
> > directives and directory layouts?  Not even Posix has one.  This has not
> > hampered C's usability or portability.
>
> This is a good point.  It hasn't been necessary, because people have stuck
> with filenames that are supported on virtually all file systems.  As I
> told Derick a while back, I favor a similar solution for R6RS libraries.
> That is, we should all agree to give our published libraries names that
> can be mapped directly to most file systems, without encoding, and ask
> those who fail to do so to rename their libraries as necessary.
>
> If we could come up with a fully general encoding mechanism, i.e., one
> that works for all existing and future filesystems, I might be more
> inclined to support encoding.  But this doesn't appear to be possible, so
> I prefer the social solution.

I love that Scheme symbols may have characters other languages disallow.
I can't support not being able to name libraries with the same freedom
as with all other symbols, nor allowing the flaws of prevalent OSs to
determine libraries' names, nor asking that library-name symbols like
'and-let* be renamed like 'and-let-star.  We have a different situation
than C.

The upcoming revision is explicit that it is for unixoids and Windoze.
When they finally die, so will this SRFI.  Scheme systems implementing
this SRFI may still do something else for other OSs, which may be
addressed by other SRFIs.

The social solution has the problem that people would be guessing what
characters they shouldn't use, leading back to the current situation of
trying to get everyone to be consistent.  Unfortunately, we can't remove
the OS restrictions which make the additional feature of encoding
necessary.  Fortunately, the encoding is simple and we can flush it and
this SRFI entirely in the future when better data storage systems are
prevalent.  We need something which supports proper Schemely names until
then.

--
: Derick
----------------------------------------------------------------