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.
