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