Issue: PATHNAME-STREAM (Version 4)

[Masinter.pa@Xerox.COM]

This issue passed conditionally last meeting, pending a change in the
wording to not restrict streams with pathnames to "files", since some
users model a "device" as something that isn't a "file". I rewrote the
description and edited the language of other parts of the proposal.

!
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)
               Version 3 by Masinter 11-Jun-87 (minor editing)
               Version 4 by Masinter  8-Oct-87 (rewording)



Category:     	CHANGE/CLARIFICATION

Problem Description:

CLtL says that a stream can be used as an argument and converted to a
pathname, but many sources or sinks of data that streams might be
connected to have no pathnames associated with them; for example,
streams created with make-two-way-stream or open-string-stream. There is
no reasonable way to coerce such a stream to a pathname.

Proposal PATHNAME-STREAM:FILES-ONLY:

Clarify that the use of a stream as an argument that expects a pathname
(as described on p413 of CLtL) only applies to streams that are
originally opened by use of the OPEN, WITH-OPEN-FILE or the like. 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.

Adoption Cost:

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

Benefits:

The description of pathname functions will make more sense.

Conversion Cost:  None.  

Aesthetics: Makes language a little cleaner.

Discussion: The cleanup committee supports this clarification.