Symbols as pathnames

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

    Date: Fri, 11 Oct 85 15:32 EDT
    From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>

	Date: Fri, 11 Oct 85 09:47:43 CDT
	From: wagner@GSWD-VMS

	On page 418 of CLtL, concerning the OPEN function:  "The filename
	...may be a string, a pathname, or a stream."  May it not also be
	a symbol, and shouldn't the spec say so?  Same for WITH-OPEN-FILE,
	etc.?  (The underlying pathname functions work with symbols.)

    It's true that most places in the manual say that symbols are acceptable
    where pathnames are required, and are parsed as namestrings.  I don't
    understand why this feature is in there; it seems like asking for trouble.
    What about implementations (yes they exist) where some streams are
    implemented as symbols?  How do you tell whether a symbol was supposed to
    be a stream or supposed to be a string?  What if NIL is accidentally used
    where a pathname was expected, do you really want to get a file named "NIL"?

    It's possible that the feature of allowing symbols as pathnames was blindly
    copied from an old version of Zetalisp, which used to allow that.  A couple
    of bad ideas got into Common Lisp that way, in spite of significant effort
    by the committee to try to keep it from happening.  Zetalisp allowed symbols
    for compatibility with an old version of pdp-10 Maclisp that didn't have
    strings.

I never saw a response to the above.  Now that we are discussing clarifications,
I'd like to suggest the following as a proposed clarification, to fix the fact
that in some places the manual says symbols are accepted as pathnames and in
other places it says they aren't.  Symbolics' implementation currently contains
some inconsistencies in this area, which cannot be corrected without deviating
from what the manual currently says in one way or another.  I'd prefer to see
all implementations deviate in the same direction.

If you reply to this message, please delete the enclosures from October, which
I only included for context.

p.413, 3rd paragraph: change "string or symbol" to "string" in both sentences.

p.413, pathname function: same.

p.414, 2nd to last paragraph: same.

p.417, pathname-host function, 1st sentence: same.

p.417, namestring function, 1st sentence: same.

p.414, parse-namestring function: delete the clause saying that @I[thing] may be
a symbol, in the second sentence.

p.415, merge-pathnames function, 3rd sentence: delete "or symbol".

p.424, probe-file function: Specify what @I[file] may be (I presume a string,
a pathname, or a stream).

p.423, rename-file function: change "@I[new-name] (which must be a filename)"
to "@I[new-name]." and add at the end of the first paragraph "@I[New-name] must
be a pathname, a string, or a stream."  I see no reason to disallow streams
here; the conversion from stream to pathname is as defined by the PATHNAME function.

p.424, file-write-date and file-author functions, also GLS's proposed extension
to the file-length function: These use the term "filename", which I cannot find
defined elsewhere.  Change "filename" to "pathname or string".

p.426, load function: This has an argument named "filename", whose type is not
defined.  Define it to be a pathname, string, or stream--the same as the
argument named "filename" for open and with-open-file.

In chapter 23, there are arguments named pathname, thing, filename, file, and
name (really new-name).  As far as I can tell there is no semantic difference
associated with these five different names.  A consistent terminology should
be adopted.  I suggest calling all of them pathname.