Re: Re: More pathname madness with #p""

>>>>> "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



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf