On Sun, 2009-10-11 at 22:34 -0400, Aubrey Jaffer wrote:
> | From: Derick Eddington <xxxxxx@gmail.com>
>  | 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
----------------------------------------------------------------