Thinking about whether or not the previously mentionned issue about the printing of (MAKE-PATHNAME :DIRECTORY '(:RELATIVE)) has a standard-mandated answer, I found that when *PRINT-READABLY* is non-nil, you are NOT ALLOWED to print something that doesn't read back similarly. Which means that a compliant implementation MAY NOT print (MAKE-PATHNAME :DIRECTORY '(:RELATIVE)) as #P"" in these conditions, and thus must include a test when printing it, so as to either print something that reads back correctly or else issue an error, the former option being more useful.
http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/var_stprint-readablyst.html http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/sec_3-2-4-2-2.html Now, if you print it as #P"./", then the same issue happens with (MAKE-PATHNAME :DIRECTORY '(:RELATIVE ".")) that, if it is valid at all, the standard distinguishes from the former, since it has different pathname components. A compliant implementation may issue an error when seeing such pathnames, or it may use the previously-mentionned trick of having one more "./" in the namestring as there are "." after :RELATIVE. Happily, the specification of PARSE-NAMESTRING leaves enough system-dependence to allow for such tricks. Does it not? http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/fun_parse-namestring.html In any case, you are not allowed to ignore this issue. Expect a twisted mind somewhere to add a case in the GCL test suite. Note that the specification of *print-readably* as either printing a readable object or issueing an error might also have other consequences on a compliant lisp implementation, when printing a variety of objects other than pathnames. "Your mission, should you choose to accept it, is to make your common lisp implementation comply fully with the ANSI standard as designed by the X3J13 committee. As always, should you or any of your IM Force be caught or killed, the Secretary will disavow any knowledge of your actions. Good luck." [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Committee, n.: A group of men who individually can do nothing but as a group decide that nothing can be done. -- Fred Allen On 30/08/05, Faré <[EMAIL PROTECTED]> wrote: > 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.
