Re: [clisp-list] Problems with MAKE-PATHNAME in clisp

[Kent M P. <pi...@wo...>]

   Date: 12 Nov 2001 17:44:18 -0500
   From: Sam Steingold <sd...@gn...>

   > * In message <200111121914.OAA08468@TheWorld.com>
   > * On the subject of "[clisp-list] Problems with MAKE-PATHNAME in clisp"
   > * Sent on Mon, 12 Nov 2001 14:14:54 -0500
   > * Honorable Kent M Pitman <pi...@wo...> writes:
   >
   > In CLISP
   > "2.27.2 (released 2001-10-05) (built 3214510376) (memory 3214510483)"
   > 
   > if I do
   > 
   >  (make-pathname :name "FOO" :case :common :defaults #P"/home/kent/")
   > 
   > I get back #P"/HOME/KENT/foo" where I expect #P"/home/kent/foo".

   this bug was introduced on 2001-07-20 in an attempt to to make the
   following work (from a pathname test suite posted to c.l.l in July):

   (defun foo (x)
     (let ((path (make-pathname
		  :defaults (make-pathname :directory
					   '(:relative :wild-inferiors)
					   :type x :case :common)
		  :host "CL-LIBRARY" :case :common)))
       (string= x (pathname-type path))))

   (foo "c")
    ==> t

   (foo "C")
    ==> t

I believe this is wrong.  IMO, both should return NIL.  They should return
T if you use :case :common to retrieve the type.  The change in case
is unpredictable if you store using :common case and retrieve with
:local case (which is lamentably the default if :case is not supplied).

   You message, as well as issue PATHNAME-COMPONENT-CASE, appear to
   indicate that :CASE does _not_ apply to the :DEFAULTS argument to
   MAKE-PATHNAME (I.e., FOO should return NIL, not T).
   Is this correct?

Well, :case does not apply to any pathname.  :case is about a translation
mode when storing or retrieving individual components as strings.  The
actual internal case you use is not specified.  

But yes, my personal opinion is that FOO should return NIL.

LispWorks Enterprise 4.1.20 returns NIL.  (I checked this AFTER
deciding what I thought it should return, so my opinion counts as an
independent guess.)

I was going to check it in Allegro but my test license has expired. Sigh.

   If it is, I can easily fix the problem (by reverting to the previous
   behavior, which was taking the stuff out of defaults as is and putting
   it into the new pathname as is).

Let me see if I can explain what I think this is all about.

The purpose of common case is to solve the problem of defaulting between
hosted pathnames that have different notions of canonical case.  e.g.,
grabbing the NAME part from a TOPS-20 pathname and the TYPE part from
a Unix pathname.  The idea is to do a fetch during merging of any
given slot in :common and to store it in the same mode.  That way, it will
change case naturally to the proper case of the new system.  That's
what MERGE-PATHNAMES should do, for example.  But in the case of 
MAKE-PATHNAME, the user manually  calls PATHNAME-NAME and friends for
purposes the system doesn't know, so the user has to remember to do
the store back in the same mode. The system has lost track of the data
path between the extract and restore and so can't assure a consistent use
of :COMMON.

Note that in some Lisp implementations, and  yours may be one, it
might also work to consistently use :LOCAL.  I've never thought this through.
But in the general case, if you have access to file systems with
opposite notions of what case is canonical, if you extract in :LOCAL case
from a TOPS-20 you'll get "FOO" in the normal case of <JDOE>FOO.LISP
and when you store the same "FOO" back in :LOCAL to a Unix pathname,
you'll get FOO.lsp instead of foo.lsp.  But if you only have Unix
pathnames, it would work to use :local to both extract and deposit components.
(The reason I say I'm unsure is I don't recall what the canonical case
is for logical pathnames, and am too lazy to go look at this moment.
If it's uppercase, as I suspect it is, then 
 (make-pathname
    :host my-logical-host
    :name (pathname-name my-unix-pathname :type :local)
    :case :local)
will accidentally flip the case while
 (make-pathname
    :host my-logical-host
    :name (pathname-name my-unix-pathname :type :common)
    :case :common)
will not.

   Thanks for the bug report.
   (I wish all our users were as clear as to what and _WHY_ they did not
   like!)

Not a problem.