Re: upcoming revision, need feedback R. Kent Dybvig (11 Jan 2010 20:52 UTC)
Re: upcoming revision, need feedback Derick Eddington (12 Jan 2010 02:11 UTC)
Re: upcoming revision, need feedback R. Kent Dybvig (12 Jan 2010 03:52 UTC)
Re: upcoming revision, need feedback Thomas Bushnell BSG (12 Jan 2010 04:24 UTC)
Re: upcoming revision, need feedback Derick Eddington (12 Jan 2010 06:18 UTC)
Re: upcoming revision, need feedback Thomas Bushnell BSG (12 Jan 2010 06:27 UTC)
Re: upcoming revision, need feedback Derick Eddington (12 Jan 2010 07:05 UTC)
Re: upcoming revision, need feedback Thomas Bushnell BSG (12 Jan 2010 07:16 UTC)
Re: upcoming revision, need feedback Derick Eddington (12 Jan 2010 09:00 UTC)
Re: upcoming revision, need feedback R. Kent Dybvig (27 Jan 2010 20:58 UTC)
Re: upcoming revision, need feedback Derick Eddington (28 Jan 2010 00:45 UTC)
Re: upcoming revision, need feedback Vitaly Magerya (28 Jan 2010 10:39 UTC)
Re: upcoming revision, need feedback Derick Eddington (28 Jan 2010 17:45 UTC)

Re: upcoming revision, need feedback Thomas Bushnell BSG 12 Jan 2010 04:01 UTC

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, and yet, at the same
time, incorporates at a deep level assumptions about what file names
are.

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

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.