[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: PATHNAME-SYMBOL (Version 3)
- To: CL-Cleanup@sail.stanford.edu
- Subject: Issue: PATHNAME-SYMBOL (Version 3)
- From: Masinter.pa@Xerox.COM
- Date: 23 Oct 87 16:32 PDT
- Cc: Masinter.pa@Xerox.COM
- Line-fold: 80
This hasn't been discussed since last June. Has anyone any further
thoughts? I moved some of the discussion around in this version, and
summarized some of the banter in the previous mail. I made the proposal
more explicit by mentioning all of the affected functions.
Since CLtL is fairly specific about "filename ... may be a stream, a
pathname, or a string" I said merely to reiterate it in this proposal.
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)
Cleanup issue PATHNAME-STREAM
Edit History: Version 1 by Moon 11-May-87
Version 2 by Masinter 29-May-87
Version 3 by Masinter 23-Oct-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. 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 are changed to not allow symbols
for their pathname argument.
Reiterate that (as implied by their respective descriptions in CLtL)
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
Allowing symbols for pathnames was based on an obsolete practice in
MacLisp (which did not have strings) and causes much error-prone
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.
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.
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
"FOO"). This is not explicitly allowed in CLtL, so such behavior has not
Improved by the change.
Some users have reported that they thought MERGE-PATHNAMES was in error
because it accepted symbols.
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
"If a symbol can be coerced into a string, and a string can be coerced
into a pathname, I see no reason why a symbol should not be coerced
into a pathname. It has limited usefulness, but I believe that
coercions should be transitive."
- Eric Benson
"Note that 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
If we cannot have consistency, let us then have consistency of
inconsistency. (Also known as, "This screw-up was good enough
for grampa, and it's good enough for me!")
-- Guy Steele