Christophe Rhodes  <csr21@cam.ac.uk> wrote:
+---------------
| rpw3@rpw3.org (Rob Warnock) writes:
| >     > (namestring (make-pathname :directory '(:ABSOLUTE "tmp" "foo")
| > 				 :name "bar"))
| >     "/tmp/foo/bar"
| >     > (namestring (make-pathname :directory '(:ABSOLUTE "tmp" "foo" "bar")))
| >     "/tmp/foo/bar/"
| >
| > So namestrings need *some* convention to distinguish the 3rd & 4th
| > cases [1st and 2nd as edited - CSR] otherwise you couldn't get the
| > same pathname back [second invariant above].
| 
| What makes you assume that either or both of these pathnames must have
| a namestring?  Your argument assumes this property, but it's certainly
| not the case that all pathnames have namestrings.
+---------------

Good point. I was specifically addressing Peter's particular question,
but you're absolutely right that in general:

	19.1.2 Pathnames as Filenames
	...
	In addition, pathnames can also represent certain partially
	composed filenames for which an underlying file system might
	not have a specific namestring representation. 
	...
	A pathname need not correspond to any file that actually exists...
	...
	There exist conceivable pathnames for which there is no mapping
	to a syntactically valid filename in a particular implementation.

And so on.

But for Unix/Linux-based platforms [and maybe even Windows?], I would
opine that the trailing slash convention is a "reasonable" choice for
an implementation-defined mapping of directories to namestrings, as it
matches users' expectations given what other system utilities tend to
do (e.g., Unix shells with filename completion tend to stick a "/" on
when the completed file name is a directory, etc.).

IMHO, pathname/namestring conversion invariance is a "nice" property,
if/when you can get it.


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607