[R6RS] File names
Wed Jan 21 16:44:55 EST 2004
> Marc> I think we can start talking about a set of filesystem
> Marc> operations that will eventually form the filesystem library.
> The hard part about this is not the functionality but the abstractions
> for filenames. The abstractions I've looked at (Java, Common Lisp,
> MzScheme, Emacs Lisp, scsh, and Scheme 48) are all pretty ad-hoc, as
> they don't really abstract over the underlying string representation.
> However, this aspect is crucial to a good design, as the typical
> string representations of Unix-like systems has many very unpleasant
> and unexpected properties.
> I guess the only way to get something usable is to assume the presence
> of a hierarchical filesystem. (Even though I keep hoping hierarchical
> filesystems will be among the first things against the wall when the
> revolution comes.)
> I once had a student elaborate an idea of mine where filenames were
> abstract. The system would distinguish between absolute filenames and
> relative filenames; a relative filename is essentially a mapping from
> one absolute filename to another. The design worked out pretty well,
> but there's not a great deal of practical experience with it. It's
> radically different from everything I've seen anywhere else.
> Do we want to tackle this issue?
The web has imposed a standard de-facto. I don't think that we
could/should escape from a notation everybody is familiar with. Even
Win32 users are now used to the Unix convention...
Since we are talking of file names, for the records, here is an extension
I have in Bigloo. Actually, I have stolen an idea from STklos that
Erick Gallesio has stolen from the web browsers or from QT
(I don't remember). A file name is something such as
filename ::= <a plain file name>
| <a protocol>:<a plain file name>
This syntax can be used everywhere. Hence, we can write things such as:
(open-input-file "string:foo bar") [== (open-input-string "foo bar")]
(with-input-from-file "pipe:ls -l"
(lambda () (read)))
May be this syntax is not perfect. However, I think that it has two
1- It sounds familiar to everyone.
2- It is concise and, in practice, very convenient.
More information about the R6RS