Issue: PATHNAME-SYMBOL (Version 4)

[Masinter.pa@Xerox.COM]

I added a reference (Wilensky) and cleaned up the discussion and
mentioned some of the other points that came up in the discussion but
haven't been addressed separately. I suppose I need to assign issue
names for extending COERCE to PATHNAME and requiring STREAM to be
disjoint, although I'm not sure if we want to generalize those to
extending COERCE in lots of ways, and requiring more than STREAM to be
disjoint.

!
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), LOAD (p. 426)
                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


Category:     	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. 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 by this proposal to not
allow symbols for their pathname argument.

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 as explicitly stated.

Rationale:

Allowing symbols for pathnames was based on an obsolete practice in
MacLisp (which did not have strings) and causes much error-prone
behavior.

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. 

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

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.

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.

Aesthetics:

Improved by the change.

Discussion:

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 sequences.

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.