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.
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?
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.
[ Fran=E7ois-Ren=E9 =D0VB Rideau | Reflection&Cybernethics | http://fare.tu=
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=E9 <fahree@...> 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)
> =3D> #P""
> (MAKE-PATHNAME :DIRECTORY '(:RELATIVE))
> =3D> #P""
> clisp, allegro and lispworks agree that it is a good idea to print the
> latter as follows
> =3D> #P"./"
> which of course pushes back the problem when you try to print
> (MAKE-PATHNAME :DIRECTORY '(:RELATIVE "."))
> =3D> #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=E7ois-Ren=E9 =D0VB Rideau | Reflection&Cybernethics | http://fare.=
> The reason truth is stranger than fiction is that fiction has to make sen=