Re: Issue: PATHNAME-STREAM (Version 5)

[Masinter.pa@Xerox.COM]

Some arguments against requiring synonym streams to delegate pathname
follow. None of these individually are compelling; I'd like to hear from
some of the rest of you on this issue.

- - - - - -
a)  If the pathname of a stream has any requirement attached to it at
all, it would seem to be the requirement that, in the absence of any
external manipulation of the data or file system, one should be able to
use the pathname retrieve the same data. While "file" streams have some
implicit requirement here, synonym streams do not -- not any more than
concatenated streams, broadcast streams, or the like.

b)   I can easily imagine extending pathnames to include non-file
streams, e.g., 

(open (make-pathname :host :broadcast :name (list stream-1 stream-2))
:direction :output)
== (make-broadcast-stream stream-1 stream-2)

(open (make-pathname :host :synonym :name '*terminal-io*) :direction
:both)
== (make-synonym-stream '*terminal-io*)

(open (make-pathname :host :string :name x) :direction :input)
== (make-string-input-stream x)

In such a design, the pathname for synonym, broadcast, concatenated,
etc. streams would reflect their current state.

c) To put it in CLOS terms, I'd expect PATHNAME to not be implemented
only for file stream classes; requiring PATHNAME to work on synonym
streams only adds another (unnecessary) method to the implementation.

d) Current practice is mixed: at least two implementations (Coral,
Xerox) do not implement meaningful pathnames for synonym streams. (Coral
signals an error, Xerox returns a null pathname. VaxLisp and Symbolics
delegate.)

- - - - - - - - -

I'd like to have this issue address in more detail what the "pathname"
of a stream is and can be expected to do; I think that elucidating what
we expect out of a pathname will help decide cases like synonym streams.