>>>>> "Raymond" == Raymond Toy <[EMAIL PROTECTED]> writes:
>>>>> "Fare" == Far <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
