[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pathnames.



    Date: Fri, 11 Oct 85 23:27 EDT
    From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>

	Date: Friday, October 11, 1985  08:53:50
	From: schumacher%hplabs.csnet@CSNET-RELAY.ARPA

	  Date: Thu, 10 Oct 85 20:42 EDT
	  From: "David C. Plummer" <hplabs!DCP%scrc-quabbin.arpa@CSNET-RELAY>

	    Date: Thu 10 Oct 85 16:06:07-PDT
	    From: SCHUMACHER%hplabs.csnet@CSNET-RELAY.ARPA

	    The manual doesn't state explicitly that the accessor functions for
	    pathname objects are setf'able.  Is this an oversight on my part,  the 
	    manuals part,  or is there some justification for this.  Admittedly the 
	    desired effect can be achieved using make-pathname with the current
	    pathname as the :default and the desired change specified as a keyword
	    arg,  but this seems sort of strange ...

	  Symbolics interns our pathnames.  Is SYMBOL-NAME setf'able?

	I'm not sure I understand this statement (question?).  Are you interning
	the namestring of the pathname ?  Perhaps I should have been more specific:
	given a path name (setq foo (pathname "<dir>foo.bar")) I want to change the 
	type field of pathname foo to be "jnk".  Is it legal cl to say 
	(setf (pathname-type foo) "jnk") ?  If this isn't legal then it seems that
	the only way to do this is (setq foo (make-pathname :type "jnk" :defaults foo)).
	Is that any clearer ?

    Perhaps I can clarify.  In Common Lisp it is not legal to change the components
    of a pathname, for the same reasons that it is not legal to change the name of
    a symbol and not legal to change the denominator of a ratio.

    In Symbolics' implementation, every time you ask for a pathname with the same
    components, you get the same object, so that pathname equality can be tested
    with EQ.  This is what DCP was pointing out.  However, this is irrelevant.
    Even in a system that didn't "intern" or "canonicalize" pathnames in this way,
    it would be inappropriate to perform side-effects on a pathname because it
    might be in use by someone else.  That's the basis for the language design;
    unfortunately it isn't explained in the manual.  You're correct that the way
    to get a pathname that is like another pathname but with one component different
    is to call make-pathname.

Perhaps SETF of pathname components should work the same
way as SETF of LDB.