| 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 approach of SRFI-104 exposes to the programmer
file-system details like separators which would normally only be used
when gluing together paths.  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))))

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.  So I think SRFI-104 could benefit from building on
SRFI-59.