Re: [Sbcl-devel] Re: More pathname madness with #p""
> "Raymond" == Raymond Toy <[EMAIL PROTECTED]> writes: > "Fare" == Far writes: Fare> On 31/08/05, Todd Sabin <[EMAIL PROTECTED]> wrote: >>> So an implementation should >>> never give you a pathname with (:relative) as the directory component, >>> and it seems perfectly legal for implementations to say that >>> (make-pathname :directory '(:relative)) is either illegal, or means >>> the same as (make-pathname :directory nil). Fare> That sounds like a plausible interpretation, if indeed there is no Fare> usage rule that distinguishes a directory NIL from a directory Fare> '(:RELATIVE). But then, because of the read-write similarity Fare> requirement, the canonicalization should happen within MAKE-PATHNAME, Fare> that should either refuse '(:RELATIVE) and issue an error or (perhaps Fare> more helpful to the user) check for it and canonicalize to NIL. Raymond> If it's allowed for make-pathname to do these kinds of manipulations, Raymond> I think this is what we should do. Yes, the CLHS entry for make-pathname says Whenever a pathname is constructed the components may be canonicalized if appropriate. So we can convert '(:relative) to nil. Likewise, '(:relative "." "." "foo") should be canonicalized to '(:relative "foo"). (For unix filesystems, which is all we currently support.) Making these changes results in a lisp that passes the same ansi-tests tests as before, except we fail a pathname-match-p test (see mail on cmucl-imp about this), which seems to be a bug in pathname-match-p, not this change. Ray
Re: [Sbcl-devel] Re: More pathname madness with #p""
> "Fare" == Far writes: Fare> On 31/08/05, Todd Sabin <[EMAIL PROTECTED]> wrote: >> So an implementation should >> never give you a pathname with (:relative) as the directory component, >> and it seems perfectly legal for implementations to say that >> (make-pathname :directory '(:relative)) is either illegal, or means >> the same as (make-pathname :directory nil). Fare> That sounds like a plausible interpretation, if indeed there is no Fare> usage rule that distinguishes a directory NIL from a directory Fare> '(:RELATIVE). But then, because of the read-write similarity Fare> requirement, the canonicalization should happen within MAKE-PATHNAME, Fare> that should either refuse '(:RELATIVE) and issue an error or (perhaps Fare> more helpful to the user) check for it and canonicalize to NIL. If it's allowed for make-pathname to do these kinds of manipulations, I think this is what we should do. Another interesting case is (make-pathname :directory '(:relative "/")). This is printed as #p"//". "/" is an illegal component, so I think make-pathname should produce a warning or an error. Likewise for (make-pathname :directory '(:absolute "abc/def")). I have a patch to do this, but I need to do some testing. Ray
Re: More pathname madness with #p""
On 31/08/05, Todd Sabin <[EMAIL PROTECTED]> wrote: > So an implementation should > never give you a pathname with (:relative) as the directory component, > and it seems perfectly legal for implementations to say that > (make-pathname :directory '(:relative)) is either illegal, or means > the same as (make-pathname :directory nil). That sounds like a plausible interpretation, if indeed there is no usage rule that distinguishes a directory NIL from a directory '(:RELATIVE). But then, because of the read-write similarity requirement, the canonicalization should happen within MAKE-PATHNAME, that should either refuse '(:RELATIVE) and issue an error or (perhaps more helpful to the user) check for it and canonicalize to NIL. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Whatever you do will be insignificant, but it is very important that you do it. -- Gandhi
Re: More pathname madness with #p""
Faré <[EMAIL PROTECTED]> writes: > 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"./" > [...] > The whole issue boggles my mind. Now it can boggle yours, too. > > Hopefully no more language lawyering for today. Pathnames aren't really my bag, but I thought about this a little, and I don't think there's a problem. According to the CLHS, the directory argument to MAKE-PATHNAME must be "a valid pathname directory", where that is defined by the glossary: valid pathname directory n. a string, a list of strings, nil, :wild, :unspecific, or some other object defined by the implementation to be a valid directory component. The list (:relative) apparently doesn't qualify, unless it's "defined by the implementation...". Unfortunately, 19.2.2.5 is slightly contradictory, but says pretty much the same thing: * The directory can be a list of strings and symbols. There are * implementation-dependent limits on the list's length and * contents. and * Any component can be taken from the corresponding component of * another pathname. But that would seem to allow passing (:relative), provided you got it from some other pathname. However, 19.2.2.4.3 says this (among other things) about the directory component of pathnames: A list whose car is the symbol :relative represents a directory path starting from a default directory. The list (:relative) has the same meaning as nil and hence is not used. The list (:relative "foo" "bar") represents the directory named "bar" in the directory named "foo" in the default directory. Note the second sentence in particular. So an implementation should never give you a pathname with (:relative) as the directory component, and it seems perfectly legal for implementations to say that (make-pathname :directory '(:relative)) is either illegal, or means the same as (make-pathname :directory nil). Does that make sense? -- Todd Sabin <[EMAIL PROTECTED]>
Re: More pathname madness with #p""
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.
