On Sep 10, 2009, at 6:31 PM, Aubrey Jaffer wrote:

> SLIB solved these problems years ago.  The notion of file location is
> abstrcted into "vicinities", of which SRFI-59 specifies five:
>
>  program-vicinity
>  library-vicinity
>  implementation-vicinity
>  user-vicinity
>  home-vicinity
>
> The procedure SUB-VICINITY can access sub-directories.
>
> SRFI-59 says:
>  Vicinities need not be tied to individual files in a file system.
>  The files named could be members of a zip archive, as Java does.
>  Vicinities can even be used on flat file systems (which have no
>  directory structure) by having the vicinity express constraints on
>  the file name.  On most systems a vicinity is a string.


As a general concept, this appears to be a renaming of "directory".  
There are plenty of systems which allow "directories" to be accessed  
which are the members of a zip archive, remote network shares, and  
other virtual resources. Is there something I'm missing?

As a specific instantiation, I have a significant problem with the  
specification of `program-vicinity'. How can an ordinary procedure  
like `program-vicinity' return information about where its call was  
located? This needs to be syntax in order to work properly, or the  
call needs to be on the right-hand side of a let-syntax. (This is why  
you see things like (LOAD-TIME-VALUE *LOAD-TRUENAME*) or #.*COMPILE- 
FILE-PATHNAME* in Common Lisp.)
--
Brian Mastenbrook
[email protected]
http://brian.mastenbrook.net/

_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss

Reply via email to