Issue: PATHNAME-SYMBOL (Version 3)

[Masinter.pa@Xerox.COM]

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.

!
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

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

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 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
pathname argument. 

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.

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.

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.

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"). This is not explicitly allowed in CLtL, so such behavior has not
been portable.

Aesthetics:

Improved by the change.

Discussion:

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


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

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