Issue: PATHNAME-SYMBOL (Version 2)

[Masinter.pa@Xerox.COM]

Status:		Merged comments in. Ready for release? [Use ballot]

Issue:		PATHNAME-SYMBOL

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

Problem Description:

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.


Proposal PATHNAME-SYMBOL:NO

Never allow symbols where pathnames are expected.

Rationale:

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.  However, the feature has
been
long since removed from Zetalisp, since it was found to be a source of
bugs
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
Common Lisp.

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.

Current Practice:

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.

Adoption Cost:

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.

Benefits:

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.

Conversion Cost:

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").

Aesthetics: Improved by the change.

Discussion:

Some users have reported the "fact" that MERGE-PATHNAMES was in error
because it accepted symbols.

The Cleanup committee supports this change.