From: Tim Bradshaw
Subject: PARSE-NAMESTRING use in CL
Date: 
Message-ID: <TIM.91Apr29103808@kahlo.cstr.ed.ac.uk>
[I'm asking this without having exhaustively read the part of either
CLtL on file system interface, so forgive stupidity.]

Most of the CL functions & macros which look at files take either a
pathname or a string as an argument to specify the file.  The function
PARSE-NAMESTRING takes such a string and converts it to a pathname.

Question: should the other file functions use PARSE-NAMESTRING to get
pathnames? 

The reason I would like this is that I can then modify this in some
way and it will affect all file operations so long as I use stringy
file names.  In particular I can make it substitute environment vars
(HOME &c) on Unix machines.  On the other hand, perhaps I can do all
this with logical pathnames?

Experiment indicates that Allegro CL / Sun4 does do this, Kyoto CL /
Sun4 does not.

--tim
From: Barry Margolin
Subject: Re: PARSE-NAMESTRING use in CL
Date: 
Message-ID: <1991Apr29.170101.23905@Think.COM>
In article <·················@kahlo.cstr.ed.ac.uk> ···@cstr.ed.ac.uk (Tim Bradshaw) writes:
>Most of the CL functions & macros which look at files take either a
>pathname or a string as an argument to specify the file.  The function
>PARSE-NAMESTRING takes such a string and converts it to a pathname.
>
>Question: should the other file functions use PARSE-NAMESTRING to get
>pathnames? 

How CL functions work inside is not specified.  They can do whatever they
want as long as they are equivalent.  The following two sets of functions
are equivalent as far as this requirement goes:

(defun open (pathname ...)
  (unless (typep pathname 'pathname)
    (setq pathname (parse-namestring pathname)))
  ...)

and

(defun open (pathname ...)
  (unless (typep pathname 'pathname)
    (setq pathname (parse-namestring-internal pathname)))
  ...)
(defun parse-namestring (namestring ...)
  (parse-namestring-internal ...))

In the first case, OPEN may inherit changes made to PARSE-NAMESTRING, but
in the second case it won't.  Furthermore, CL functions are permitted to be
open-coded, so even in the first case redefining PARSE-NAMESTRING might not
affect OPEN.

>The reason I would like this is that I can then modify this in some
>way and it will affect all file operations so long as I use stringy
>file names.  In particular I can make it substitute environment vars
>(HOME &c) on Unix machines.  On the other hand, perhaps I can do all
>this with logical pathnames?

Redefining standard Common Lisp functions is not portable, for the above
reasons, and CLtL2 makes this clear (see p.260).

>Experiment indicates that Allegro CL / Sun4 does do this, Kyoto CL /
>Sun4 does not.

And Symbolics CL still calls many Zetalisp functions internally.
--
Barry Margolin, Thinking Machines Corp.

······@think.com
{uunet,harvard}!think!barmar