Suppose I want to make an encapsulated stream (say an echo stream)
that will track changes to a well-known stream variable such as
*standard-input*. I can make it like this:

  (make-echo-stream (make-synonym-stream '*standard-input*) my-output-stream)

Now if someone changes or rebinds *standard-output* while I'm still
using the echo stream, it will pick up on the change. Whereas if I
made the echo stream like:

  (make-echo-stream *standard-input* my-output-stream)

it would keep using the stream referenced by *standard-input* at the
time the echo stream was made, even if *standard-input* is later reset
or rebound. A similar situation could arise when making a broadcast
stream.

Is that it? Or is there some other use that I'm totally missing?

-Peter

--
Peter Seibel                                      pe...@javamonkey.com

It's so you can have interdependent "well-known variables".  In particular,
it allows *standard-input*, *standard-output*, *query-io*, and *debug-io*
to be synonym streams to *terminal-io* without having to rebind anything
other than *terminal-io* to change the "focus of attention" to another
window.  On the Lisp Machine, *terminal-io* (which was very badly named),
meant what might better have been called *current-window*.

Unfortunately, because hte hygiene for maintaining window focus is
ill-specified in CL in general, being left to implementations, you
mostly can't use it in this way.  You could, of course, make similar
mechanisms of your own, so that you only had to bind one focus variable
in order to change things.

Note that LispWorks, for example, just makes *terminal-io* go to some
tty-like window that I, for one, never want to talk to.  I think they
decided (alas) that this icky DOS-like window was the "terminal".  The
window more resembles what the Lisp Machine would call the "cold load
stream", the court of last resort in debugging. The
intended abstraction, I think, by those who created this set of names,
would have been that they would have let that be *terminal-io* until
they had bootstrapped their way into multiprocessing, and then would
have re-bound *terminal-io* per process, leaving *standard-input* and
friends alone (because they'd be synonym streams).  By the time I found
what they'd one (which is not non-conforming, as far as I know, just
not what I and others intended), I'm not sure there was any way to get
them to back out of it.

Nor are they likely to be the only ones who  did this.  I think there
are other implementations that have said that there is always a
*standard-input* and *standard-output*, like stdin and stdout, but
that sometimes there is no (or no useful) *terminal-io* if windowing
operaitons of some class are not supported.  THis is again, not what I
think would have been intended, but the spec is so vague that there's
no real way to prevent it.

-Peter

--
Peter Seibel                                      pe...@javamonkey.com

 Nevertheless, I'll interpret your question as one about Maclisp,
 circa 1979-1980, just before CL, since was what I was talking about.]

Plus people were always finding bugs and sometimes when JonL White couldn't
fix them, he'd just put in a breakpoint acknowledging the problem and who
had reported it, so you'd be running along and see
 ;BKPT PSZ LOSES
or some such thing, indicating that there was work remaining to do in
coding something you'd thought was fully working...

It was fun (when it was) mostly because of two things: (1) we didn't
distribute the code, we mostly used it locally and all our users
dialed in, so when we needed a fix, installing it "worldwide" was not
that hard and (2) our livelihood did not depend upon its correctness.
we weren't commercial, we were sponsored research staff.

But after a while I got tired of being told my code had changed meaning
and that it was my responsibility to update it.  My code meant what I
meant it to mean, even when broken by changes, and that little joke about
how it had changed meaning and to please "update my program" wore thin
after a while...

The idea of the synonym-stream was an attempt to provide a layer of
stream indirection and a mechanism capable of rapid lambda binding
of stream capability depending on, well, lambda binding.  It was and
remains a horrible `kludge' (q.v.) because it make streams, if not
fully second-class objects, something less than first class.  The
important aspects of the identity of a synonym stream are not
discernable by eq, and the important aspects of its behavior are not
discernable by class-of or type-of, and do not even remain constant
within a single function body.

-Peter

--
Peter Seibel                                      pe...@javamonkey.com

Synonym streams present two practical problems.  First, the operational
class of the stream is not apparent via the actual class of the stream.
Second, any function that is part of some higher layer implemented on
streams (e.g. draw-rectangle) must be extended to work with a
synonym-stream.  Plausible safety nets to do this automatically such as
no-applicable-method typically have unacceptable overhead or
indirectness.

is this objection specific to synonym streams? is not make-synonym-stream
typical of the standard cl stream operations in that it is reluctant to
support specialization? in which sense synonym-stream is not in itself an obstacle.

are there arguments against relying on special variables, as opposed to slot
values, for delegation attributes? wrt the encapsulation ==> robust and
predictable issue, there's not much difference between an uninterned symbol
and a slot value.

If one's focus considering streams is the implementation of the parochial
ANS stream capabilities, everything is merely an implementation strategy
and the details don't matter at all to the user programmer.  But the ANS
avoids most of the obvious real-world real-computing-universe requirements
on streams.  In the age of MACLISP, everything interesting passed through
a tty.  Today, nothing interesting interesting passes through a tty.

as i noted in my earlier query, delegation in lisp depends on a binding for
the referent. synonym streams effect this with a special variable.
object-based delegation can support it with a slot binding. it would be
possible to do it with closed-over variables, but i'm not acquainted with
implementation which use that technique. given this requirement, that is, that
the referent is bound somewhere, the only difference i can discern between the
special-binding-based delegation and the slot-based delegation is, well, the
nature of the binding.

if i take a tiny example. let's say i would like to generate svg. i have these
data objects which need to be serialized. in order to support delegation,
there has to be some provision for it in the api protocol.

in this case, the base generic function and default definitions are all
generated via
macros. like

(defProjectionOp line (l1 l2 &optional properties))
(defProjectionOp line*2 (x1 y1 x2 y2 &optional properties))
(defProjectionOp line*3 (x1 y1 z1 x2 y2 z2 &optional properties))

in order to provide for delegation - or whatever sort - i would think that
there has to be a definition somewhere which looks something like

(defmethod op ((instance delegate) &rest args)
  (apply #'op (delegate-referent instance) args))

are there alternatives? given that, the generation function for delegatable
operations needs an additional clause. some thing like

(push `(:method ((delegate delegate-context) ,@lambda-list)
                (,do-call #',operator-name
                     (delegate-referent delegate) ,@arguments))
      methods)

which is not that complex and provides for any class which specializes
delegate-context and implements delegate-referent. it is not material whether
the class specializes synonym-stream or some other abstract class. assuming
that the projection operations above are so defined, the alternative
delegation forms do not look very different.

(defClass svg-presenter () ()
  (:documentation
   "the protocol class which specifies the presence of the svg presentation methods"))

(defClass svg-context (aspect-context)
  ((stream
    :initform nil :initarg :stream
    :reader context-stream
    :documentation "bound to an output stream for svg-envoded output."))
  (:documentation
   "a context which implements graphics operations as svg serialization."))

(defclass svg-wrapper-context (delegate-context svg-presenter stream)
  ((context :reader effective-context :initarg :context))
  (:documentation
   "a wrapper which implements svg presentation methods through delegation to
a context which implements graphics operations."))

(defParameter *svg-output* nil)

(defClass svg-synonym-context (delegate-context svg-presenter synonym-stream)
  ()
  (:default-initargs :symbol '*svg-output*)
  (:documentation
   "a synonym context which delegates through a spacial variable binding
rather than a slot binding."))

(defMethod effective-context ((synonym-context svg-synonym-context))
  (symbol-value (synonym-stream-symbol synonym-context)))

[ ignoring the stream operations which the wrapper needs to act as a stream ]

the concrete serialization looks something like this

(defun svg-line*3 (x1 y1 z1 x2 y2 z2 &optional aspects)
  "serialize a line given the 3d location"
  #+og.assert-types (progn (assert-types (x1 y1 z1 x2 y2 z2) number)
                           (assert-type aspects sequence))
  (flet ((emit-line ()
           (xml ({svg}line ({}x1  x1) ({}y1  y1)
                           ({}x1  x2) ({}y1  y2)
                           ({}stroke *svg-stroke-color*)))))
    (declare (dynamic-extent #'emit-line))
    (call-with-aspects #'emit-line aspects)))

(defMethod .og.::line*3 ((context svg-context) x1 y1 z1 x2 y2 z2 &optional aspects)
  "draw a line given two extreme 3d vertices"
  (svg-line*3 x1 y1 z1 x2 y2 z2 aspects))

(defMethod .og.::line*2 ((context svg-context) x1 y1 x2 y2 &optional aspects)
  "draw a line given two extreme 2d vertices"
  (svg-line*3 x1 y1 0.0d0 x2 y2 0.0d0 aspects))

(defMethod .og.::line ((context svg-context) l1 l2 &optional aspects)
  "draw a line given the end locations (2-d or 3-d) in object/world coordinates"
  ;; ignoring that svg is only 2d
  (with-location-coordinates (((x1 y1 z1) l1) ((x2 y2 l2) l2))
    (svg-line*3 x1 y1 z1 x2 y2 l2 aspects)))

the projection interface looks something like this

(defgeneric present (instance context)
  (:method ((instance line) (context svg-presenter))
           (line context (location instance) (end instance)
                       (presentation-properties instance context))))

and the usage looks something like this

(defParameter *svgc* (make-instance 'svg-context :stream *trace-output*))
;(context-stream *svgc*)

(defParameter *svg-wc* (make-instance 'svg-wrapper-context :context *svgc*))
;(effective-context *svg-wc*)
;(context-stream (effective-context *svg-wc*))

(defParameter *svg-sc* (make-instance 'svg-synonym-context :symbol '*svg-output*))

(setq *svg-output* *svg-wc*)

(with-projection-context (*svgc*)
  (let ((line (make-instance 'line
                :location #@(|3| 0.0 0.0 0.0)
                :end #@(|3| 1.0 1.0 1.0))))
    (format *svg-wc* "~%~%<!-- presenting to a svg-wrapper-context: -->~%")
    (present line *svg-wc*)
    (format *svg-sc* "~%~%<!-- presenting to a svg-synonym-context: -->~%")
    (present line *svg-sc*)))

wherein i discern no difference between synonym classes and wrapper classes.
do the problems surrounding a terminal-stream-with-double-spacing a
clim:presenting-stream has a shape which is so different from this?