References: PATHNAME (p.413),
Derived references: PARSE-NAMESTRING (p.414),
MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
NAMESTRING etc. (p.417), LOAD (p. 426), REQUIRE
Cleanup issue PATHNAME-STREAM
Common LispCraft, Wilensky 1986, p 51
Edit History: Version 1 by Moon 11-May-87
Version 2 by Masinter 29-May-87
Version 3 by Masinter 23-Oct-87
Version 4 by Masinter 23-Nov-87
Version 5 by Masinter 5-Feb-88, fix minor typo
Some Common Lisp functions are specified to accept a symbol where a pathname is
expected. Some others (OPEN, WITH-OPEN-FILE, DELETE-FILE, and RENAME-FILE) are
not specified to accept a symbol.
Never allow symbols where pathnames are expected. More specifically, PATHNAME,
TRUENAME, PARSE-NAMESTRING, MERGE-PATHNAMES, PATHNAME-HOST, PATHNAME-DEVICE,
PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION, NAMESTRING,
FILE-NAMESTRING, DIRECTORY-NAMESTRING, HOST-NAMESTRING, ENOUGH-NAMESTRING,
REQUIRE are changed by this proposal to not allow symbols for their pathname
Reiterate that OPEN, WITH-OPEN-FILE, LOAD, COMPILE-FILE, RENAME-FILE,
DELETE-FILE, FILE-WRITE-DATE, FILE-AUTHOR do not allow symbols for their file or
filename argument, and that DIRECTORY does not allow a symbol for its pathname
argument. This is implied by the respective descriptions of those functions in
CLtL, but not explicitly stated.
Allowing symbols for pathnames was based on an obsolete practice in MacLisp
(which did not have strings) and causes much error-prone behavior.
Varies. Some implementations allow symbols here, some don't. Symbolics doesn't
allow symbols except in PARSE-NAMESTRING and MERGE-PATHNAMES, and allowing them
there is probably a bug in the implementation.
Cost to implementors:
It's easy to change implementations to stop accepting symbols. Since this
appears to be an "is an error" rather than "signals an error" situation, no
implementation change is actually necessary.
Cost to users:
Some users might be using symbols as pathnames, in implementations where that
works, and they would have to switch to using strings. For example, some users
are used to typing interactively (LOAD 'FOO) to mean (LOAD "FOO"). This is not
explicitly allowed in CLtL, so such behavior has not been portable. However,
such use is probably widespread among users of implementations that allow it
(e.g., Common LISPCraft gives this form in an example.)
Pathname functions will be more consistent. In implementations that check the
type of this argument, program error checking will be improved. In dealing with
case-sensitive file systems, users won't do (load 'foo) and wonder why file
"FOO" (rather than "foo") is not found.
One example of the type of bug caused by this occurs when NIL is erroneously
substituted for a pathname, perhaps because GETHASH or ASSOC didn't find a table
entry that was expected to exist and returned -false-. In systems that accept
symbols as pathnames, this causes a reference to a file named "NIL" on some
perhaps unexpected directory.
Improved by the change.
Some users have reported that they thought MERGE-PATHNAMES was in error because
it accepted symbols.
We believe that this feature was accidentally introduced as a historical
artifact and that it has limited utility. It is likely that the feature of
accepting a symbol was copied by Common Lisp from Zetalisp, which in turn copied
it from Maclisp. The reason Maclisp allowed a symbol here was that it did not
have strings at all. While the feature was removed from Zetalisp before Common
Lisp was defined due to the poor state of Zetalisp documentation at the time the
change was overlooked by the designers of Common Lisp.
If a symbol can be coerced into a string, and a string can be coerced into a
pathname, why can't a symbol be coerced into a pathname? An explicit decision
was made early in the design of CL not to make all coercions transitive. For
example, symbols coerce to strings (for string functions), and strings are
sequences (and so can be mixed with other sequence types), but symbols are not
There is some sentiment for extending COERCE to allow explicit coersion of
STRINGs to PATHNAMEs, as a separate cleanup item.
A careful reading of CLtL indicates that it is possible for an implementation to
allow a symbol to be a STREAM (there is no requirement that STREAM and SYMBOL be
disjoint.) While there is some sentiment for making this requirement in a
separate cleanup issue, it would otherwise prevent both symbol->pathname and
stream->pathname to have consistent meaning.