From: <fa...@gm...> - 2005-08-31 02:53:44
|
I *think* that cmucl, sbcl and openmcl are wrong when they reply (ENOUGH-NAMESTRING #P"/a/b/c" #P"/")=20 =3D> "/a/b/c" instead of replying =3D> "a/b/c" like clisp and gcl do. In < http://lisp.org/HyperSpec/Body/fun_namestrin_h-namestring.html >, the Holy CLHS specifies: enough-namestring returns an abbreviated namestring that is just sufficient to identify the file named by pathname when considered relative to the defaults. It is required that (merge-pathnames (enough-namestring pathname defaults) defaults) =3D=3D (merge-pathnames (parse-namestring pathname nil defaults) defaults) in all cases, and the result of enough-namestring is the shortest reasonable string that will satisfy this criterion. It seems to me that in this particular case, "a/b/c" is reasonable enough, and thus must be preferred over "/a/b/c". But I'm not a registered language lawyer. In cl-launch, I'll work around this bug by using translate-pathname with (merge-pathnames #"**/*.*" ...). I hope I'm not digging deeper... Riastradh comments (about the cmucl and sbcl implementations): I think you'd just need to take out the (> PREFIX-LEN 1) from UNPARSE-UNIX-ENOUGH in order to fix this...in filesys.lisp. Hope this helps, [ Fran=E7ois-Ren=E9 =D0VB Rideau | Reflection&Cybernethics | http://fare.tu= nes.org ] Lie, n.: A very poor substitute for the truth, but the only one discovered to date. |
From: <fa...@gm...> - 2005-08-31 03:23:22
|
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.tu= nes.org ] The reason truth is stranger than fiction is that fiction has to make sense= . |
From: <fa...@gm...> - 2005-08-31 04:41:16
|
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_stpri= nt-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=E7ois-Ren=E9 =D0VB Rideau | Reflection&Cybernethics | http://fare.tu= nes.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=E9 <fa...@gm...> 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: >=20 > (MAKE-PATHNAME :DIRECTORY NIL) > =3D> #P"" >=20 > (MAKE-PATHNAME :DIRECTORY '(:RELATIVE)) > =3D> #P"" >=20 > 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... >=20 > The whole issue boggles my mind. Now it can boggle yours, too. >=20 > Hopefully no more language lawyering for today. >=20 > [ Fran=E7ois-Ren=E9 =D0VB Rideau | Reflection&Cybernethics | http://fare.= tunes.org ] > The reason truth is stranger than fiction is that fiction has to make sen= se. |
From: <fa...@gm...> - 2005-08-31 06:01:51
|
On 31/08/05, Mike McDonald <mi...@mi...> wrote: >=20 > With the exception of logical pathnames, NAMESTRING and > PARSE-NAMESTRING are "implementation dependant". If your program is > expecting a particular behavior across implementations, it is > expecting too much. Use logical pathnames if you're concerned about > "conformance". > Well, NAMESTRING and PARSE-NAMESTRING are "implementation dependent", but if PN is a PATHNAME the fact that (PARSE-NAMESTRING (NAMESTRING PN)) should be *similar* to PN, which the standard specifies as meaning all its pathname components are similar, or else (WRITE PN) should throw an error of type PRINT-NOT-READABLE when *READ-EVAL* is NIL and *PRINT-READABLY* it T. (See CLHS about *PRINT-READABLY*.) NB: I note that SBCL is not compliant when printing a hash-table under such constraints, because it throws an error of type SIMPLE-ERROR instead of PRINT-NOT-READABLE. CMUCL does the right thing. > As for *print-readably*, it only requires that an object, when read > back in, is "similar" to the original object. A couple of years ago, > we had a LONG, heated thread about what "similar" meant. According to > the spec lawyers/CL committee member(s), it means absolutely nothing! > (I disagreed with that interpretation but didn't get much support.) Similarity is specified in section 3.2.4.2 of the standard in such a way that does not obviously "mean absolutely nothing". And section 3.2.4.2.2 specifically mentions pathnames. If you know (e.g. USENET) arguments that make those requirements meaningless, they deserve at least to be linked to from some relevant page. http://lisp.org/HyperSpec/Body/sec_3-2-4-2.html [ Fran=E7ois-Ren=E9 =D0VB Rideau | Reflection&Cybernethics | http://fare.tu= nes.org ] Science is like sex: sometimes something useful comes out, but that is not the reason we are doing it -- Richard Feynman |
From: Marco A. <ma...@cs...> - 2005-08-31 14:59:11
|
On Aug 31, 2005, at 2:01 AM, Far=E9 wrote: > On 31/08/05, Mike McDonald <mi...@mi...> wrote: >> >> With the exception of logical pathnames, NAMESTRING and >> PARSE-NAMESTRING are "implementation dependant". If your program is >> expecting a particular behavior across implementations, it is >> expecting too much. Use logical pathnames if you're concerned about >> "conformance". >> > Well, NAMESTRING and PARSE-NAMESTRING are "implementation dependent", > but if PN is a PATHNAME the fact that (PARSE-NAMESTRING (NAMESTRING > PN)) should be *similar* to PN, which the standard specifies as > meaning all its pathname components are similar, or else (WRITE PN) > should throw an error of type PRINT-NOT-READABLE when *READ-EVAL* is > NIL and *PRINT-READABLY* it T. (See CLHS about *PRINT-READABLY*.) The origin of PN may make things hairy here. Note that Apart from that, and I am playing devil's advocate here, if you read=20 back the null string you can expect a DIRECTORY of NIL (check the spec=20= about PARSE-NAMESTRING). >> As for *print-readably*, it only requires that an object, when read >> back in, is "similar" to the original object. A couple of years ago, >> we had a LONG, heated thread about what "similar" meant. According to >> the spec lawyers/CL committee member(s), it means absolutely nothing! >> (I disagreed with that interpretation but didn't get much support.) > > Similarity is specified in section 3.2.4.2 of the standard in such a > way that does not obviously "mean absolutely nothing". And section > 3.2.4.2.2 specifically mentions pathnames. If you know (e.g. USENET) > arguments that make those requirements meaningless, they deserve at > least to be linked to from some relevant page. > http://lisp.org/HyperSpec/Body/sec_3-2-4-2.html The similarity requirement for pathnames is (as with many things in the=20= pathnames) ill defined, as no rules are set for doing things in a=20 certain way on a given file system. Which brings up the question. =20 What should PARSE-NAMESTRING do on a UNIX system and what should the=20 printer do on a pathname on a UNIX system? Cheers -- Marco Antoniotti = http://bioinformatics.nyu.edu NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 715 Broadway 10th FL fax. +1 - 212 - 998 3484 New York, NY, 10003, U.S.A. |
From: Christophe R. <cs...@ca...> - 2005-09-02 20:45:11
|
Far=C3=A9 <fa...@gm...> writes: > NB: I note that SBCL is not compliant when printing a hash-table > under such constraints, because it throws an error of type > SIMPLE-ERROR instead of PRINT-NOT-READABLE. CMUCL does the right > thing. Thank you for the report; this is fixed in sbcl-0.9.4.24. Cheers, Christophe |
From: Raymond T. <ray...@er...> - 2005-08-31 13:38:52
|
>>>>> "Fare" == Far <Far> writes: Fare> The IRC discussion spawned by my previous bug report raised the point Fare> of read-write invariance of #p syntax, and the fact that once again, Fare> cmucl, sbcl and openmcl (and gcl, too) might be wrong by not Fare> distinguishing the following: Fare> (MAKE-PATHNAME :DIRECTORY NIL) Fare> => #P"" Fare> (MAKE-PATHNAME :DIRECTORY '(:RELATIVE)) Fare> => #P"" Fare> clisp, allegro and lispworks agree that it is a good idea to print the Fare> latter as follows Fare> => #P"./" Fare> which of course pushes back the problem when you try to print Fare> (MAKE-PATHNAME :DIRECTORY '(:RELATIVE ".")) Fare> => #P"./" Fare> at least, it can be reasonably considered (barring funky filesystem Fare> semantics) that An alternative, at least on unix, is to make (make-pathname :directory '(:relative)) print as #p".". Currently #p"." is read as a pathname with name ".", but if we change that to return a directory, then we're ok. But of course, we would then lose for (make-pathname :name "."), but there isn't really a unix file with name "."; it's a directory. I hate this stuff. Ray |
From: Raymond T. <ray...@er...> - 2005-08-31 13:34:01
|
>>>>> "Fare" == Far <Far> writes: [snip] Fare> Riastradh comments (about the cmucl and sbcl implementations): Fare> I think you'd just need to take out the (> PREFIX-LEN 1) from Fare> UNPARSE-UNIX-ENOUGH in order to fix this...in filesys.lisp. I think this is almost right. It should be (>= prefix-len 1) in case the prefix has an nil directory. Thanks for the report! Ray |
From: Todd S. <ts...@op...> - 2005-08-31 14:48:38
|
Far=E9 <fa...@gm...> writes: > The IRC discussion spawned by my previous bug report raised the poi= nt > 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"./" > [...] > 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, an= d I don't think there's a problem. According to the CLHS, the director= y 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, :wil= d, :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 =66rom some other pathname. However, 19.2.2.4.3 says this (among oth= er 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? --=20 Todd Sabin <tsabin@optonline= .net> |
From: <fa...@gm...> - 2005-08-31 18:21:31
|
On 31/08/05, Todd Sabin <ts...@op...> 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=E7ois-Ren=E9 =D0VB Rideau | Reflection&Cybernethics | http://fare.tu= nes.org ] Whatever you do will be insignificant, but it is very important that you do= it. -- Gandhi |
From: Raymond T. <ray...@er...> - 2005-09-01 16:19:38
|
>>>>> "Fare" == Far <Far> writes: Fare> On 31/08/05, Todd Sabin <ts...@op...> 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 |
From: Raymond T. <ray...@er...> - 2005-09-07 13:10:36
|
>>>>> "Raymond" == Raymond Toy <ray...@er...> writes: >>>>> "Fare" == Far <Far> writes: Fare> On 31/08/05, Todd Sabin <ts...@op...> 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 |