This page is part of the web mail archives of SRFI 59 from before July 7th, 2015. The new archives for SRFI 59 contain all messages, not just those from before July 7th, 2015.
It seems rather behind-the-times to talk about "a place in the file system." In 2005 we should be using the language of URIs to talk about "places". I suggest re-working this SRFI to talk about URIs rather than vicinities. Specifically, replace "base vicinity" by "absolute URI". The in-vicinity function should be replaced by a "resolve-uri" function which "resolves" a URI (possibly relative) against a "base" (usually absolute) URI. The user-vicinity function could be replaced by a "base-uri" function, which default to the "current directory". Note that in practice one can view a filename/-path as a URI relative to the current directory without ambguity except for some rare pathological cases. (Among the latter are filenames containing '%'.) So one appealing option is to generalize load, open-input-filename etc to take a URI *or* filename: (load "http://foo.com/bar.scm") If the string is a relative URI, it is resolved relative to the value of base-uri, which defauls to the current directory. I've been toying iwth implementing this for Kawa, but haven't gotten around to it. The Java API for the URI class provides a useful summary from an API focus: http://java.sun.com/j2se/1.5.0/docs/api/java/net/URI.html RFC 2396 is the actual standard: http://www.ietf.org/rfc/rfc2396.txt -- --Per Bothner per@xxxxxxxxxxx http://per.bothner.com/