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.
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.
--
: Derick
----------------------------------------------------------------