Issue: PATHNAME-STREAM (Version 2)

[Masinter.pa@Xerox.COM]

Status:          Ready to release?

Issue:         PATHNAME-STREAM

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),
               OPEN (p.418), WITH-OPEN-FILE (p.422),
               RENAME-FILE (p.423), DELETE-FILE (p.424)

Edit History:  Version 1 by Moon 11-May-87
               Version 2 by Masinter 29-May-87 (minor editing)

Category:     	CHANGE/CLARIFICATION

Problem Description:

The PATHNAME function as documented in CLtL is impossible to implement.
CLtL says that a stream can be used as an argument and converted to a
pathname, but pathnames only name files, not other sources or sinks of
data that streams might be connected to.

Proposal PATHNAME-STREAM:FILES-ONLY:

Specify that if a stream is used as a pathname, it must be a stream that
is or was open to a file. For example, it is an error to attempt to
obtain a pathname from a two-way-stream or a string-stream.

Rationale:

This is probably what the designers of Common Lisp intended. This is the
only thing that can be implemented without large changes to the language
such as extending pathnames to things other than files. 

Current Practice:

Some systems signal an error if a non-file stream is used as a pathname.
Others may do something else, but since the proposal is to define this
to be "is an error", current practice seems irrelevant.

Adoption Cost:

Since the proposal says only "is an error" rather than "signals an
error", no implementations need change.

Benefits: Description of pathname functions will make more sense.

Conversion Cost: We believe no existing user code relies on any values.

Aesthetics: Makes language a little cleaner.

Discussion: The cleanup committee supports this clarification.