Issue: PATHNAME-SYMBOL

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

Issue:		PATHNAME-SYMBOL
		[Note that this is not the same issue as PATHNAME-STREAM]

Status:		New issue

References:   	PATHNAME (p.413), also the introductory text right above
		it on the same page.
		Derived references: PARSE-NAMESTRING (p.414),
		MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
		NAMESTRING etc. (p.417).

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.

Conversion Cost:

Some users might be using symbols as pathnames, in implementations where
that works, and they would have to switch to using strings.

Aesthetics: Improved by the change.

Discussion:

The only user feedback on this issue I've seen was a bug report that
MERGE-PATHNAMES was in error because it accepted symbols.