[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: STREAM-CAPABILITIES
- To: vanroggen%aitg.DEC@decwrl.dec.com
- Subject: Re: Issue: STREAM-CAPABILITIES
- From: masinter.pa@Xerox.COM
- Date: 20 Sep 88 02:16 PDT
- Cc: firstname.lastname@example.org
- In-reply-to: vanroggen%aitg.DEC@decwrl.dec.com's message of Wed, 14 Sep 88 07:29:16 PDT
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,
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
The STREAM-SOURCE-ID-LIST proposal has some merits, but reminds me of Godel
Dans reasoning "Pierson supports STREAM-CAPABILITIES:NEW-PREDICATES because he
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.