Re: Issue: STREAM-CAPABILITIES

[masinter.pa@Xerox.COM]

Yes, its not so much the necessity of STREAM-SAME-xxx-P as it is the likelihood
of them being correctly implementable for any of the likely operating systems,
especially in the presence of network file systems, pipes, streams, indirects,
redirects, etc.

I think adding something that cannot be correctly implemented will lead to more
rather than less portable code.

I think INTERACTIVE-STREAM-P is implementable, however, if only because it is
reasonable to be conservative.
It is important to answer the questions about CL-constructed streams lest we
differ: what about MAKE-ECHO-STREAM MAKE-BROADCAST-STREAM MAKE-TWO-WAY-STREAM
with regard to their transformation of INTERACTIVE-STREAM-Ps to non-interactive
ones? 

The STREAM-SOURCE-ID-LIST proposal has some merits, but reminds me of Godel
numbering schemes.

Dans reasoning "Pierson supports STREAM-CAPABILITIES:NEW-PREDICATES because he
is
concerned that it may be hard for implementations to provide the list
functions efficiently because the natural token type for multiple,
disjoint types of streams may be integers.  The implementation would
have to coerce these integers in to some other type of token that
would be guaranteed unique across all possible stream types." 

doesn't follow from the proposal, does it? Some streams could have integers as
tokens (are you thinking of their inode number or something?), and others not.