143 lines
11 KiB
HTML
143 lines
11 KiB
HTML
<!-- Common Lisp HyperSpec (TM), version 7.0 generated by Kent M. Pitman on Mon, 11-Apr-2005 2:31am EDT -->
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>CLHS: Issue PATHNAME-SYMBOL Writeup</TITLE>
|
|
<LINK HREF="../Data/clhs.css" REL="stylesheet" TYPE="text/css" />
|
|
<META HTTP-EQUIV="Author" CONTENT="Kent M. Pitman">
|
|
<META HTTP-EQUIV="Organization" CONTENT="LispWorks Ltd.">
|
|
<LINK REL=TOP HREF="../Front/index.htm">
|
|
<LINK REL=COPYRIGHT HREF="../Front/Help.htm#Legal">
|
|
<LINK REL=DISCLAIMER HREF="../Front/Help.htm#Disclaimer">
|
|
<LINK REL=PREV HREF="../Issues/iss263_w.htm">
|
|
<LINK REL=UP HREF="../Issues/iss264.htm">
|
|
<LINK REL=NEXT HREF="../Issues/iss265_w.htm">
|
|
</HEAD>
|
|
<BODY>
|
|
<H1><A REV=MADE HREF="http://www.lispworks.com/"><IMG WIDTH=80 HEIGHT=65 ALT="[LISPWORKS]" SRC="../Graphics/LWSmall.gif" ALIGN=Bottom></A><A REL=TOP HREF="../Front/index.htm"><IMG WIDTH=237 HEIGHT=65 ALT="[Common Lisp HyperSpec (TM)]" SRC="../Graphics/CLHS_Sm.gif" ALIGN=Bottom></A> <A REL=PREV HREF="../Issues/iss263_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss264.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss265_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
<H2>Issue PATHNAME-SYMBOL Writeup</H2>
|
|
|
|
<PRE><B>Issue:</B> <A HREF="iss264.htm">PATHNAME-SYMBOL</A><P>
|
|
<P>
|
|
<B>References:</B> <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>PATHNAME</B></A> (p.413),<P>
|
|
Derived references: <A REL=DEFINITION HREF="../Body/f_pars_1.htm#parse-namestring"><B>PARSE-NAMESTRING</B></A> (p.414),<P>
|
|
<A REL=DEFINITION HREF="../Body/f_merge_.htm#merge-pathnames"><B>MERGE-PATHNAMES</B></A> (p.415), <A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-host"><B>PATHNAME-HOST</B></A> etc. (p.417),<P>
|
|
<A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>NAMESTRING</B></A> etc. (p.417), <A REL=DEFINITION HREF="../Body/f_load.htm#load"><B>LOAD</B></A> (p. 426), <A REL=DEFINITION HREF="../Body/f_provid.htm#require"><B>REQUIRE</B></A> <P>
|
|
Cleanup issue <A HREF="iss261_m.htm">PATHNAME-STREAM</A><P>
|
|
Common LispCraft, Wilensky 1986, p 51<P>
|
|
<P>
|
|
<P>
|
|
<B>Edit History:</B> Version 1 by Moon 11-May-87<P>
|
|
Version 2 by Masinter 29-May-87<P>
|
|
Version 3 by Masinter 23-Oct-87<P>
|
|
Version 4 by Masinter 23-Nov-87<P>
|
|
Version 5 by Masinter 5-Feb-88, fix minor typo<P>
|
|
<P>
|
|
<P>
|
|
<B>Category:</B> CHANGE<P>
|
|
<P>
|
|
<B>Problem Description:<P>
|
|
</B><P>
|
|
Some Common Lisp functions are specified to accept a symbol where a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> is<P>
|
|
expected. Some others (<A REL=DEFINITION HREF="../Body/f_open.htm#open"><B>OPEN</B></A>, <A REL=DEFINITION HREF="../Body/m_w_open.htm#with-open-file"><B>WITH-OPEN-FILE</B></A>, <A REL=DEFINITION HREF="../Body/f_del_fi.htm#delete-file"><B>DELETE-FILE</B></A>, and <A REL=DEFINITION HREF="../Body/f_rn_fil.htm#rename-file"><B>RENAME-FILE</B></A>) are<P>
|
|
not specified to accept a symbol.<P>
|
|
<P>
|
|
Proposal PATHNAME-SYMBOL:NO<P>
|
|
<P>
|
|
Never allow symbols where pathnames are expected. More specifically, <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>PATHNAME</B></A>,<P>
|
|
<A REL=DEFINITION HREF="../Body/f_tn.htm#truename"><B>TRUENAME</B></A>, <A REL=DEFINITION HREF="../Body/f_pars_1.htm#parse-namestring"><B>PARSE-NAMESTRING</B></A>, <A REL=DEFINITION HREF="../Body/f_merge_.htm#merge-pathnames"><B>MERGE-PATHNAMES</B></A>, <A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-host"><B>PATHNAME-HOST</B></A>, <A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-device"><B>PATHNAME-DEVICE</B></A>,<P>
|
|
<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-directory"><B>PATHNAME-DIRECTORY</B></A>, <A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-name"><B>PATHNAME-NAME</B></A>, <A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-type"><B>PATHNAME-TYPE</B></A>, <A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-version"><B>PATHNAME-VERSION</B></A>, <A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>NAMESTRING</B></A>,<P>
|
|
<A REL=DEFINITION HREF="../Body/f_namest.htm#file-namestring"><B>FILE-NAMESTRING</B></A>, <A REL=DEFINITION HREF="../Body/f_namest.htm#directory-namestring"><B>DIRECTORY-NAMESTRING</B></A>, <A REL=DEFINITION HREF="../Body/f_namest.htm#host-namestring"><B>HOST-NAMESTRING</B></A>, <A REL=DEFINITION HREF="../Body/f_namest.htm#enough-namestring"><B>ENOUGH-NAMESTRING</B></A>,<P>
|
|
<A REL=DEFINITION HREF="../Body/f_provid.htm#require"><B>REQUIRE</B></A> are changed by this proposal to not allow symbols for their <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A><P>
|
|
argument.<P>
|
|
<P>
|
|
Reiterate that <A REL=DEFINITION HREF="../Body/f_open.htm#open"><B>OPEN</B></A>, <A REL=DEFINITION HREF="../Body/m_w_open.htm#with-open-file"><B>WITH-OPEN-FILE</B></A>, <A REL=DEFINITION HREF="../Body/f_load.htm#load"><B>LOAD</B></A>, <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A>, <A REL=DEFINITION HREF="../Body/f_rn_fil.htm#rename-file"><B>RENAME-FILE</B></A>,<P>
|
|
<A REL=DEFINITION HREF="../Body/f_del_fi.htm#delete-file"><B>DELETE-FILE</B></A>, <A REL=DEFINITION HREF="../Body/f_file_w.htm#file-write-date"><B>FILE-WRITE-DATE</B></A>, <A REL=DEFINITION HREF="../Body/f_file_a.htm#file-author"><B>FILE-AUTHOR</B></A> do not allow symbols for their file or<P>
|
|
filename argument, and that <A REL=DEFINITION HREF="../Body/f_dir.htm#directory"><B>DIRECTORY</B></A> does not allow a symbol for its <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A><P>
|
|
argument. This is implied by the respective descriptions of those functions in<P>
|
|
CLtL, but not explicitly stated.<P>
|
|
<P>
|
|
<B>Rationale:<P>
|
|
</B><P>
|
|
Allowing symbols for pathnames was based on an obsolete practice in MacLisp<P>
|
|
(which did not have strings) and causes much error-prone behavior.<P>
|
|
<P>
|
|
<B>Current Practice:<P>
|
|
</B><P>
|
|
Varies. Some implementations allow symbols here, some don't. Symbolics doesn't<P>
|
|
allow symbols except in <A REL=DEFINITION HREF="../Body/f_pars_1.htm#parse-namestring"><B>PARSE-NAMESTRING</B></A> and <A REL=DEFINITION HREF="../Body/f_merge_.htm#merge-pathnames"><B>MERGE-PATHNAMES</B></A>, and allowing them<P>
|
|
there is probably a bug in the implementation. <P>
|
|
<P>
|
|
<B>Cost to implementors:<P>
|
|
</B><P>
|
|
It's easy to change implementations to stop accepting symbols. Since this<P>
|
|
appears to be an "is an error" rather than "signals an error" situation, no<P>
|
|
implementation change is actually necessary.<P>
|
|
<P>
|
|
<B>Cost to users:<P>
|
|
</B><P>
|
|
Some users might be using symbols as pathnames, in implementations where that<P>
|
|
works, and they would have to switch to using strings. For example, some users<P>
|
|
are used to typing interactively (<A REL=DEFINITION HREF="../Body/f_load.htm#load"><B>LOAD</B></A> 'FOO) to mean (<A REL=DEFINITION HREF="../Body/f_load.htm#load"><B>LOAD</B></A> "FOO"). This is not<P>
|
|
explicitly allowed in CLtL, so such behavior has not been portable. However,<P>
|
|
such use is probably widespread among users of implementations that allow it<P>
|
|
(e.g., Common LISPCraft gives this form in an example.)<P>
|
|
<P>
|
|
<B>Benefits:<P>
|
|
</B><P>
|
|
Pathname functions will be more consistent. In implementations that check the<P>
|
|
type of this argument, program error checking will be improved. In dealing with<P>
|
|
case-sensitive file systems, users won't do (load 'foo) and wonder why file<P>
|
|
"FOO" (rather than "foo") is not found.<P>
|
|
<P>
|
|
One example of the type of bug caused by this occurs when <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A> is erroneously<P>
|
|
substituted for a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A>, perhaps because <A REL=DEFINITION HREF="../Body/f_gethas.htm#gethash"><B>GETHASH</B></A> or <A REL=DEFINITION HREF="../Body/f_assocc.htm#assoc"><B>ASSOC</B></A> didn't find a table<P>
|
|
entry that was expected to exist and returned -false-. In systems that accept<P>
|
|
symbols as pathnames, this causes a reference to a file named "NIL" on some<P>
|
|
perhaps unexpected directory.<P>
|
|
<P>
|
|
<B>Aesthetics:<P>
|
|
</B><P>
|
|
Improved by the change.<P>
|
|
<P>
|
|
<B>Discussion:<P>
|
|
</B><P>
|
|
Some users have reported that they thought <A REL=DEFINITION HREF="../Body/f_merge_.htm#merge-pathnames"><B>MERGE-PATHNAMES</B></A> was in error because<P>
|
|
it accepted symbols.<P>
|
|
<P>
|
|
We believe that this feature was accidentally introduced as a historical<P>
|
|
artifact and that it has limited utility. It is likely that the feature of<P>
|
|
accepting a symbol was copied by Common Lisp from Zetalisp, which in turn copied<P>
|
|
it from Maclisp. The reason Maclisp allowed a symbol here was that it did not<P>
|
|
have strings at all. While the feature was removed from Zetalisp before Common<P>
|
|
Lisp was defined due to the poor state of Zetalisp documentation at the time the<P>
|
|
change was overlooked by the designers of Common Lisp.<P>
|
|
<P>
|
|
If a symbol can be coerced into a string, and a string can be coerced into a<P>
|
|
<A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A>, why can't a symbol be coerced into a pathname? An explicit decision<P>
|
|
was made early in the design of CL not to make all coercions transitive. For<P>
|
|
example, symbols coerce to strings (for string functions), and strings are<P>
|
|
sequences (and so can be mixed with other sequence types), but symbols are not<P>
|
|
sequences.<P>
|
|
<P>
|
|
There is some sentiment for extending <A REL=DEFINITION HREF="../Body/f_coerce.htm#coerce"><B>COERCE</B></A> to allow explicit coersion of<P>
|
|
STRINGs to PATHNAMEs, as a separate cleanup item.<P>
|
|
<P>
|
|
A careful reading of CLtL indicates that it is possible for an implementation to<P>
|
|
allow a symbol to be a <A REL=DEFINITION HREF="../Body/t_stream.htm#stream"><B>STREAM</B></A> (there is no requirement that <A REL=DEFINITION HREF="../Body/t_stream.htm#stream"><B>STREAM</B></A> and <A REL=DEFINITION HREF="../Body/t_symbol.htm#symbol"><B>SYMBOL</B></A> be<P>
|
|
disjoint.) While there is some sentiment for making this requirement in a<P>
|
|
separate cleanup issue, it would otherwise prevent both symbol->pathname and<P>
|
|
stream->pathname to have consistent meaning.<P>
|
|
<P>
|
|
</PRE>
|
|
<HR>
|
|
|
|
<A REL=NAVIGATOR HREF="../Front/StartPts.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Starting Points]" SRC="../Graphics/StartPts.gif" ALIGN=Bottom></A><A REL=TOC HREF="../Front/Contents.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Contents]" SRC="../Graphics/Contents.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Master.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Index]" SRC="../Graphics/Index.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Symbol.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Symbols]" SRC="../Graphics/Symbols.gif" ALIGN=Bottom></A><A REL=GLOSSARY HREF="../Body/26_a.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Glossary]" SRC="../Graphics/Glossary.gif" ALIGN=Bottom></A><A HREF="../Front/X3J13Iss.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Issues]" SRC="../Graphics/Issues.gif" ALIGN=Bottom></A><BR>
|
|
|
|
<A REL=COPYRIGHT HREF="../Front/Help.htm#Legal"><I>Copyright 1996-2005, LispWorks Ltd. All rights reserved.</I></A><P>
|
|
</BODY>
|
|
</HTML>
|