[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: PATHNAME-SYMBOL (Version 2)
- To: CL-Cleanup@sail.stanford.edu
- Subject: Issue: PATHNAME-SYMBOL (Version 2)
- From: Masinter.pa@Xerox.COM
- Date: 29 May 87 21:23 PDT
- Cc: Masinter.pa@Xerox.COM
Status: Merged comments in. Ready for release? [Use ballot]
References: PATHNAME (p.413),
Derived references: PARSE-NAMESTRING (p.414),
MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
NAMESTRING etc. (p.417).
Edit History: Version 1 by Moon 11-May-87
Version 2 by Masinter 29-May-87
Category: (Incompatible) CHANGE
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.
The feature of accepting a symbol was copied by Common Lisp from
which in turn copied it from Maclisp. The reason Maclisp allowed a
here was that it did not have strings at all. However, the feature has
long since removed from Zetalisp, since it was found to be a source of
and not to be useful. I suspect this feature was removed from Zetalisp
before Common Lisp was defined, but due to the poor state of Zetalisp
documentation at the time the change was overlooked by the designers of
One example of the type of bug caused by this occurs when NIL is
substituted for a pathname, perhaps because GETHASH or ASSOC didn't find
table entry that was expected to exist and returned -false-. In systems
that accept symbols as pathnames, this causes a reference to a file
"NIL" on some perhaps unexpected directory.
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.
It's easy to change implementations to stop accepting symbols. Since
appears to be an "is an error" rather than "signals an error" situation,
no implementation change is actually necessary.
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.
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 type interactively (LOAD 'FOO) to mean (LOAD
Aesthetics: Improved by the change.
Some users have reported the "fact" that MERGE-PATHNAMES was in error
because it accepted symbols.
The Cleanup committee supports this change.