[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
re: synonym streams..
- To: common-lisp@su-ai
- Subject: re: synonym streams..
- From: David Bein <pyramid!bein@hplabs.HP.COM>
- Date: Tue, 26 Aug 1986 04:48:00 -0000
Regarding David Moon's comment about what sensible programmers should do,
I agree wholeheartedly. It is somewhat clearer that streams come
in more flavors than just what OPEN will return (as currently defined
in both CLtL and various LispMachine manuals for existing implementations).
David's suggestion seems to omit the need for making streams more usable.
Closing down a stream (whether it be the product of some composite
operation like make-broadcast-stream or not) is a reasonable thing
to want to do. I think the issue here is deciding whether or not
the programmer/user has an adequate amount of flexibility in
ONE QUESTION for the designers:
Why was there no function like
where function gets passed both streams and does input from <input-stream>
filtering it in some way and possibly doing some output to
I really wish that the original specification for streams had
included itself in the typing system. I feel that it would have
been cleaner to define one function called:
(stream-message stream :keyword <...>)
much in the object-oriented spirit. I can think of some esoteric
methods I would have added certainly, but the most important ones
include being able to differentiate amongst streams, interrogating
streams and applying a handful of options to alter how close behaves
on any stream.
Below the ====='ed line is my proposal.
I welcome comments,modifications,critcisms, et al to the proposal
(typep stream 'stream)
(stream-message stream :type)
Returns stream type, e.g. synonym-stream.
This should return something rather specialized.
Those who feel that TYPE-OF would answer this
need might consider what kinds of hair seem
to be in most implementations of TYPE-OF.
(stream-message stream :operations)
Returns a list of operations which make
sense for this stream. Defined to not
recurse into streams underneath.
(typep stream 'broadcast-stream)
(stream-message stream :broadcasters)
Returns a list of the streams to broadcast to.
(typep stream 'synonym-stream)
(stream-message stream :synonym)
Returns the symbol which the stream is synonymous with.
(stream-message stream :sanity-check)
Returns T if the stream contains no loops like
the kind which bite KMP and others (me too). Otherwise,
returns NIL which means that this stream is inherently
unsafe. NOTE: I know this is out of place and definitely
smells bad. I could live with out this one I guess.
(or (typep stream 'two-way-stream)
(typep stream 'echo-stream))
(stream-message stream :input)
Returns the input stream.
(stream-message stream :output)
Returns the output stream.
(I think of echo streams as a specialization of two-way streams.)
(typep stream 'concatenated-stream)
(stream-message stream :sources)
Returns a list of the input streams.
(typep stream 'stream) ;; CLOSE attributes
(stream-message stream :close-forever)
Marks this stream as one which CLOSE
should render unsuable and which
should have CLOSE applied to its
children. This is the DEFAULT for
streams produced by OPEN or
(stream-message stream :close-never)
Marks this stream as always open.
A CLOSE will not look to see if
this stream has children.
(stream-message stream :close-parent)
Marks this stream as one which CLOSE
renders unusable but does not touch
any streams underneath.
(stream-message stream :close-children)
Marks this stream as one which never closes
but a CLOSE applied to it will be applied
to streams underneath.
(typep stream 'stream) ;; CLOSE and ERROR
(stream-message stream :close-no-error)
Permit this stream to be CLOSEd. This
is the DEFAULT for streams produced by
(stream-message stream :close-error)
Marks this stream in such a way that
a CLOSE of it causes an error. Handy for
things like (close *terminal-io*) where
it probably does not make sense to close it.