This page is part of the web mail archives of SRFI 104 from before July 7th, 2015. The new archives for SRFI 104 contain all messages, not just those from before July 7th, 2015.
On Sun, 2009-10-11 at 22:34 -0400, Aubrey Jaffer wrote: > | From: Derick Eddington <derick.eddington@xxxxxxxxx> > | Date: Wed, 07 Oct 2009 13:23:45 -0700 > | > | On Wed, 2009-10-07 at 13:34 -0400, Aubrey Jaffer wrote: > | > SRFI-103 should have some text comparing SRFI-59 to SRFI-103 and > | > explaining why the conventions of SRFI-59 are inadequate to your > | > goals for SRFI-103. > | > | Thanks for pointing-out SRFI-59. I just read it for the first > | time. I need more time and sleep to think about it, but right now > | I'm thinking it probably is not a fit for this SRFI, and I probably > | can succinctly describe why in the document of this SRFI. I'll > | return to this topic. (Anyone, feel free to comment about this if > | you want while I wait.) > > I got a chance to look at SRFI-104, and SRFI-59 is more relevant > there. There is no fundamental reason for file paths to be Unicode > strings. The correspondence between list-of-symbols library names and hierarchically organizing files is central to the purpose of this SRFI and of SRFI 103. Using abstract vicinities and abstract file names, instead of Unicode string-paths, is attractive because the abstraction would support platforms where file hierarchies are not accomplished using directories and/or where files are not named using string-paths. List-of-symbols library names could correspond to abstract nested vicinities such that each symbol, except for the last symbol for "non-implicit file names" (in SRFI 103 terminology), corresponds to a sub-vicinity in the vicinity corresponding to the previous symbol, or for the first symbol, in one of the "search vicinities" (analog of current SRFI 103's "search paths"). However, I still don't have a clear idea how integrating vicinities into SRFI 103 and SRFI 104 would affect the design and goals. Also, there are some issues which I don't think SRFI 59 can handle (more below). If those issues could be handled, then I'd be interested in exploring adopting abstract nested vicinities and abstract file names, and I'd do an experimental reworking of the reference implementation of SRFI 104 to help me concretely understand the details and ramifications. > The approach of SRFI-104 exposes to the programmer > file-system details like separators which would normally only be used > when gluing together paths. The current draft exposes the path separator on purpose, so that string-paths using separators different than the host's can be manipulated. The `path-separator' parameter can be parameterized for working with foreign string-paths. Supporting the ability to work with foreign string-paths seems necessary for a library of utilities for working with SRFI 103. E.g., a program running on a Unix-like host may want to work with Windows string-paths. The current draft does not have a reason for exposing the environment variable separator. Exposing it is left over from a prior stage of the evolution of the design when the library needed to be manually initialized. Now, the library is automatically initialized, so there is no longer any reason for exposing the environment variable separator. I will remove `environment-variable-separator', in the next revision. Thank you for helping clean this up. > Furthermore, several operating-systems' > file-systems have more than one possible separator: > > (define vicinity:suffix? > (let ((suffi > (case (software-type) > ((amiga) '(#\: #\/)) > ((macos thinkc) '(#\:)) > ((ms-dos windows atarist os/2) '(#\\ #\/)) > ((nosve) '(#\: #\.)) > ((unix coherent plan9) '(#\/)) > ((vms) '(#\: #\])) > (else > (slib:warn "require.scm" 'unknown > 'software-type (software-type)) > "/")))) > (lambda (chr) (and (memv chr suffi) #t)))) Would a string-path for any OSs with multiple separators ever contain different separators? E.g., "search/path\\foo/bar\\zab.sls"? If so, then that is a problem for the current draft, because only the same separator per string-path is supported. Different separators is supported via parameterizing `path-separator', but that only allows using different separators for different string-paths, not for the same string-path. This SRFI could be modified so that `path-separator' becomes `path-separators', which is a list of characters, any of which separate components of a string-path, and only the first of which is used for constructing string-paths. > Vicinities can be strings or some other datatype depending on the > hosting operating-system. Vicinity operations are higher level than > string operations, incorporating the separators and file-system > conventions. This is attractive. But... > So I think SRFI-104 could benefit from building on > SRFI-59. SRFI 59 does not support working with vicinities of foreign hosts. If this SRFI was based on SRFI 59, it could not support working with foreign string-paths. SRFI 59 does not have "without vicinity" nor "super vicinity" nor "vicinity name" operators. If this SRFI was based on SRFI 59, it could not support the `library-file-path-info' procedure (which I suppose would be renamed to `library-file-name-info'), because it could not be implemented because implementing it requires those operators. SRFI 59's `pathname->vicinity' is inadequate because implementing `library-file-name-info' in terms of abstract file names and abstract vicinities needs to be like: (define (library-file-name-info fn) (let loop ((v (pathname->vicinity fn)) (parts (list (without-vicinity fn)))) (if v (loop (super-vicinity v) (cons (vicinity-name v) parts)) (do-the-rest parts)))) But that's not possible with SRFI 59. -- : Derick ----------------------------------------------------------------