More pathname madness with #p""

The IRC discussion spawned by my previous bug report raised the point
of read-write invariance of #p syntax, and the fact that once again,
cmucl, sbcl and openmcl (and gcl, too) might be wrong by not
distinguishing the following:

(MAKE-PATHNAME :DIRECTORY NIL)
=> #P""

(MAKE-PATHNAME :DIRECTORY '(:RELATIVE))
=> #P""

clisp, allegro and lispworks agree that it is a good idea to print the
latter as follows
=> #P"./"
which of course pushes back the problem when you try to print
(MAKE-PATHNAME :DIRECTORY '(:RELATIVE "."))
=> #P"./"
at least, it can be reasonably considered (barring funky filesystem
semantics) that
(MAKE-PATHNAME :DIRECTORY '(:RELATIVE)) and (MAKE-PATHNAME :DIRECTORY
'(:RELATIVE ".")) are somehow equivalent in the "modern" operating
systems underlying the considered lisp implementations, whereas they
are not at all the same as (MAKE-PATHNAME :DIRECTORY NIL). I guess
that to strictly preserve read-write invariance, the number of "." in
the #P"././././" representation could be one more than the number of
"." just after the :relative...

The whole issue boggles my mind. Now it can boggle yours, too.

Hopefully no more language lawyering for today.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
The reason truth is stranger than fiction is that fiction has to make sense.


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf