tim@cstr.ed.ac.uk (Tim Bradshaw) (04/29/91)
[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
barmar@think.com (Barry Margolin) (04/30/91)
In article <TIM.91Apr29103808@kahlo.cstr.ed.ac.uk> tim@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. barmar@think.com {uunet,harvard}!think!barmar