Well, part of this is about the value of the srfi in general.  I think
it would be better if it said, explicitly, this is a suggested binding
for r6rs libraries on Unix systems, and other systems with similar
directory structures.

The C programming language has enjoyed some measure of success, and
indeed, portability, and yet, it does not mandate anything as detailed
as this, despite the existence of such things as shared libraries,
include files with slashes in their names (say, #include <sys/types.h>)
and other such things.

The reason for this is that C standards do not mandate the placement of
files in file systems, being satisfied instead merely with the correct
results when one has a #include with the right sequence of characters
between the <>.

The kicker is that this is because of two things: first, a careful and
clear separation between the language and things which are essentially
command line arguments to the compiler, and then, second, a long process
of convergence about command line arguments for the compiler and
associated tools.

I suggest that the same thing is needed here.  *Separate* the language
and the command line arguments to the compiler.  Let Scheme standards
specify the syntax and semantics of *scheme* code.  So far, Scheme
implementers are not able to agree on such simple things as whether to
bother actually implementing the Unix networking syscalls as they really
are.  This is very cart-before-horse, equivalent to mandating the way
options like -I, -C, and -L should work on the cc command line, rather
than such things as mandating Scheme semantics.

At least, if you want to go that route--and such standardization is not
a crazy idea!--make it clear that this is about bindings for Unix and
other systems, rather than wording it in the fairly generic way it is
now, and then stripping out the careful explanation of filename syntax
and such.  The srfi is for systems with that kind of filesystem, and not
for others, and that's that.  Those systems already document their
filename syntax quite satisfactorily.

Thomas

On Mon, 2010-01-11 at 22:18 -0800, Derick Eddington wrote:
> On Mon, 2010-01-11 at 20:01 -0800, Thomas Bushnell BSG wrote:
> > The thing that I rather dislike about this srfi (and here I'm speaking
> > of the draft right now on schemers.org) is the way in which it seems to
> > simultaneously be agnostic about operating system,
>
> It's not agnostic about OSs, it says things like:
>
>         Unixes and Windows are chosen as the platforms to cater to
>         because they are the prevalent contemporary platforms.
>
> and
>
>         ... using contemporary file systems ...
>
> > and yet, at the same
> > time, incorporates at a deep level assumptions about what file names
> > are.
>
> Yes, that's because the central purpose of this SRFI is to map
> list-of-symbols library names to contemporary prevalent
> file-system-entity names.
>
> > Notice that r5rs and r6rs filenames are simply strings.  Even that, on
> > some historic operating systems, is perhaps too much, but it's a
> > reasonable compromise.  But draft srfi 103 actually imposes the
> > assumption that these strings refer to hierarchically organized
> > filesystems of the vaguely Unixoid type.
> >
> > This sort of file system organization was innovatively wonderful in the
> > seventies, when there were competing systems with a simple two- or
> > three-layer system.
> >
> > So what srfi 103 assumes is that file names are hierarchically
> > organized, that these pathname components are separated by a *single*
> > os-dependent character, and so forth.  This is *way* too much.  It's
> > already too much to be mandating hierarchically organized files,
>
> As the current draft says:
>
>         This SRFI provides a method of finding library files based on
>         libraries' names by using each symbol component as a file path
>         component. The compound nature of list-of-symbols library names
>         allows for hierarchical grouping of libraries under shared name
>         prefixes, which is useful for avoiding name conflicts with
>         others' libraries and for organizing related libraries. Such
>         library names are similar to file system paths because a path is
>         a sequence of strings naming an entity in a hierarchy of
>         directories. This similarity is exploited to hierarchically
>         organize library files in the way which corresponds to
>         hierarchical library names.
>
> > but
> > this can't deal with the syntax of TOPS or VMS.  I'm not a great fan of
> > those systems, but surely we don't need to be further restrict the
> > possibilities.
>
> I'm all for better OSs, but we need a concrete standard to use with
> contemporary prevalent OSs (as much as they suck) and to support
> portability of library files between such OSs, not something so abstract
> that library files are not portable.  I think OSs which have
> data-storage models which are not compatible with this SRFI should have
> a separate SRFI.
>
> > We have here, as far as I can tell, more design-in-the-absence-of-use,
> > and this time, language design trying to mandate operating system design
> > principles.
>
> I don't follow.
>