[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: FOLLOW-SYNONYM-STREAM
- To: cl-cleanup@sail.stanford.edu
- Subject: Issue: FOLLOW-SYNONYM-STREAM
- From: Masinter.pa@Xerox.COM
- Date: 10 Jun 88 02:02 PDT
----- Begin Forwarded Messages -----
Return-Path: <@SAIL.STANFORD.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: Xerox-Common-Lispâ??.x
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 19 DEC 86 12:59:09
PST
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 Dec 86
12:22:04 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 28330; Fri 19-Dec-86
15:20:50 EST
Date: Fri, 19 Dec 86 15:19 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FOLLOW-SYNONYM-STREAM
To: Common-Lisp@SAIL.STANFORD.EDU
Message-ID: <861219151955.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
From time to time, I find myself doing:
(LET ((*TERMINAL-IO* *STANDARD-OUTPUT*))
...)
in a multi-window system in order to temporarily change my interaction to the
same window as output has been redirected to. On the Lisp Machine (and probably
on many or most other implementations), *STANDARD-OUTPUT* can sometimes (often)
contain a synonym-stream for *TERMINAL-IO* and the result of the operation
above is to send output to a stream which is a (circular) synonym for itself.
The kind of lossage this results in is fairly severe because *DEBUG-IO* is often
a synonym for *TERMINAL-IO* and if that is in turn a synonym for *TERMINAL-IO*,
then the debugger cannot run.
A couple of things would make this problem more tractable:
SYNONYM-STREAM-P object [Function]
This accepts any kind of argument. If the argument is not a synonym
stream, then NIL is returned. If the argument is a synonym stream,
then the symbol for which the object is a synonym is returned.
FOLLOW-SYNONYM-STREAM stream [Function]
This accepts a stream and returns the result of following that stream
through any number of synonym stream indirections (including zero).
While I'm on page 329, I think we should also have the following functions
(or functionalities) which I have needed at other times:
BROADCAST-STREAM-P object [Function]
CONCATENATED-STREAM-P stream [Function]
TWO-WAY-STREAM-P [Function]
...
This accepts any kind of argument. It returns T if the argument is a
{concatenated/broadcast/two-way/...} stream and NIL if the argument is
any other kind of stream.
EXPAND-BROADCAST-STREAM broadcast-stream [Function]
EXPAND-CONCATENATED-STREAM concatenated-stream [Function]
EXPAND-TWO-WAY-STREAM two-way-stream [Function]
...
This accepts a {broadcast/concatenated/two-way/...} stream and returns
a list of the streams which were used to compose it (in an order
compatible with the order of arguments to the creation function).
Note: Implementations are allowed, but not required, to return the
same list every time. The result list should not be destructively modified.
----- End Forwarded Messages -----