CLHS says

Initial Value:
implementation-dependent, but it must be an open stream that is not a
generalized synonym stream to an I/O customization variables but that
might be a generalized synonym stream to the value of some I/O
customization variable.

This doesn't make sense. So what does it actually mean ? Taking into account
what "issue" STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS says I think
the intended meaning is

.... that is not a generalized synonym stream to any of the standard I/O
customization variables but that might be a generalized synonym stream to
the value of some implementation defined I/O customization variable.

On 2024-02-17, Spiros Bousbouras <spibou@gmail.com> wrote:
> CLHS says
>
> Initial Value:
> implementation-dependent, but it must be an open stream that is not a
> generalized synonym stream to an I/O customization variables but that
> might be a generalized synonym stream to the value of some I/O
> customization variable.

This seems to be because generalized synonym stream means two things:
it can target stream objects or symbols. It seems to be saying that
*debug-io* may be the same stream as one held in another such variable,
but not an alias for such a variable itself.

In other words the requirement seems to be that if *debug-io* were, say,
the same as *stdandard-output*, and the application assigns or binds a
new value to *standard-output*, *debug-io* must not be affected.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On Sat, 17 Feb 2024 14:08:29 -0000 (UTC), Spiros Bousbouras wrote:

> CLHS says
>
> Initial Value:
> implementation-dependent, but it must be an open stream that is not
> a generalized synonym stream to an I/O customization variables but
> that might be a generalized synonym stream to the value of some I/O
> customization variable.
>
> This doesn't make sense.

It could if “an I/O customization variables” is a typo for “any I/O
customization variables”. Note that *debug-io* is in the list of these
variables in the glossary entry.

This is getting beyond my LISP-fu, but is “stream to a variable” distinct
from “stream to the value of a variable”?

On Sun, 18 Feb 2024 22:06:16 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Sat, 17 Feb 2024 14:08:29 -0000 (UTC), Spiros Bousbouras wrote:
>
> > CLHS says
> >
> > Initial Value:
> > implementation-dependent, but it must be an open stream that is not
> > a generalized synonym stream to an I/O customization variables but
> > that might be a generalized synonym stream to the value of some I/O
> > customization variable.
> >
> > This doesn't make sense.
>
> It could if “an I/O customization variables” is a typo for “any I/O
> customization variables”. Note that *debug-io* is in the list of these
> variables in the glossary entry.
>
> This is getting beyond my LISP-fu, but is “stream to a variable” distinct
> from “stream to the value of a variable”?

Based on what the CLHS page for System Class SYNONYM-STREAM says ,
I can't think of a meaningful distinction.

On 2024-02-19, Spiros Bousbouras <spibou@gmail.com> wrote:
> On Sun, 18 Feb 2024 22:06:16 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Sat, 17 Feb 2024 14:08:29 -0000 (UTC), Spiros Bousbouras wrote:
>>
>> > CLHS says
>> >
>> > Initial Value:
>> > implementation-dependent, but it must be an open stream that is not
>> > a generalized synonym stream to an I/O customization variables but
>> > that might be a generalized synonym stream to the value of some I/O
>> > customization variable.
>> >
>> > This doesn't make sense.
>>
>> It could if “an I/O customization variables” is a typo for “any I/O
>> customization variables”. Note that *debug-io* is in the list of these
>> variables in the glossary entry.
>>
>> This is getting beyond my LISP-fu, but is “stream to a variable” distinct
>> from “stream to the value of a variable”?
>
> Based on what the CLHS page for System Class SYNONYM-STREAM says ,
> I can't think of a meaningful distinction.

The glossary makes it clear. The principal meaning (1) of synonym
stream is that it's an object made by make-synonym-stream.

The target of a synonym stream is a dynamic variable name.

So if we call (make-synonym-stream '*standrad-output*) we get an
object that tracks the value of *standard-output*. If the value
of *standard-output* changes, that synonym stream becomes a
synonym to a different stream. (Note: in my dialet of English, I prefer
"synonym of" rather than "synonym to").

The Glossary also says that "synonym stream" has relative usages:
we can speak about a synonym stream to a symbol, and a synonym
stream to a stream. The latter refers to the value of a symbol.
If S is a stream which is the current value of *standard-output*,
then our above object is a synonym to that stream (at the moment),
as well as a synonym to the *standard-output* symbol.

So then, what is this:

implementation-dependent, but it must be an open stream that is not
a generalized synonym stream to an I/O customization variables but
that might be a generalized synonym stream to the value of some I/O
customization variable.

It is saying that *debug-io* cannot be a synonym stream to another such
a variable. For instance, *debug-io* will not be an object created
by (make-synonym-stream '*standard-output*). If we bind or assign
*standard-output*, *debug-io* must not change.

However, *debug-io* is allowed to be a synonym stream (thus necessarily
to some dynamic variable symbol), and that symbol can have the same
stream as *standard-output* as its initial value.

It looks like ANSI CL is trying to impose the requirement that those
stream variables are independent (not tied together as synonyms) without
imposing the requirement that they may not be generalized synonym
streams.

So this would be conforming:

(defvar sys:internal-standard-ouptut ...)

(defvar *debug-io* (make-synonym-stream 'sys:internal-standard-ouptut))
(defvar *standard-output* (make-synonym-stream 'sys:internal-standard-ouptut))

Binding/assigning *debug-io* or *standard-ouptut* has no effect on
the other, but they are initially synonyms of
sys:internal-standrad-output, and so if that variable changes, they
both change.

This is allowed because sys:internal-standard-output is not one of the
public stream variables.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

I no longer remember why we designed this whole synonym stream thing.
(Where by "we" I really mean Dan Weinreb and Dave Moon, I was mostly
just in the room when they did this.) I _think_ it is mimicking
something that the Multics I/O system does.

I'm not aware of any modern system where I/O has this feature. It is
true that modern streams are often wrapped around other streams to
compose features (a text string may wrap a binary stream which may in
turn wrap an unbuffered stream, etc.), but the idea of one stream
wrapping another as an _indirection_ mechanism, so that you can
dynamically replace the wrapped stream with a different one, seems
unique to Common Lisp.

I'm not sure what problem it solves, since I don't remember ever wanting
to use it in Common Lisp (or wishing I had something like it when
programming in Java, Python, or C). Buy maybe I'm forgetting something.

I would be interested to know of any place that _does_ use synonym
streams to solve some real problem.

- Alan

On Mon, 19 Feb 2024 17:40:29 -0000 (UTC)
Kaz Kylheku <433-929-6894@kylheku.com> wrote:
> So then, what is this:
>
> implementation-dependent, but it must be an open stream that is not
> a generalized synonym stream to an I/O customization variables but
> that might be a generalized synonym stream to the value of some I/O
> customization variable.
>
> It is saying that *debug-io* cannot be a synonym stream to another such
> a variable. For instance, *debug-io* will not be an object created
> by (make-synonym-stream '*standard-output*). If we bind or assign
> *standard-output*, *debug-io* must not change.
>
> However, *debug-io* is allowed to be a synonym stream (thus necessarily
> to some dynamic variable symbol), and that symbol can have the same
> stream as *standard-output* as its initial value.
>
> It looks like ANSI CL is trying to impose the requirement that those
> stream variables are independent (not tied together as synonyms) without
> imposing the requirement that they may not be generalized synonym
> streams.
>
> So this would be conforming:
>
> (defvar sys:internal-standard-ouptut ...)
>
> (defvar *debug-io* (make-synonym-stream 'sys:internal-standard-ouptut))
> (defvar *standard-output* (make-synonym-stream 'sys:internal-standard-ouptut))
>
> Binding/assigning *debug-io* or *standard-ouptut* has no effect on
> the other, but they are initially synonyms of
> sys:internal-standrad-output, and so if that variable changes, they
> both change.
>
> This is allowed because sys:internal-standard-output is not one of the
> public stream variables.

And how is this different from what I wrote in my opening post , namely

.... that is not a generalized synonym stream to any of the standard I/O
customization variables but that might be a generalized synonym stream to
the value of some implementation defined I/O customization variable.

?

--
vlaho.ninja/menu

On Mon, 19 Feb 2024 17:06:33 -0500
Alan Bawden <alan@csail.mit.edu> wrote:
> I no longer remember why we designed this whole synonym stream thing.
> (Where by "we" I really mean Dan Weinreb and Dave Moon, I was mostly
> just in the room when they did this.) I _think_ it is mimicking
> something that the Multics I/O system does.

Well , there does exist multicians.org/rjf.html :

Another class of DIM is one that translates one I/O call to another I/O
call, i.e., its pseudo-device is a stream. A stream that is used as a
pseudo-device is termed an object stream. The most important of this
class of DIMs is the "synonym" module. When an attachment is made via the
synonym module the specified device is another stream. Any subsequent
calls to the first stream is transformed by the synonym module to the
same call on the latter stream. The stream names are, therefore,
synonymous.

Applications

In the Multics system certain stream names are established, by
convention, for normal use. The first of these is "user_i/o". This stream
is normally associated with the use;'s primary I/O device, e.g., in a
normal console session "user_i/o" will be attached to the user's console.
Two other stream names are also established: "user_input" and
"user_output". These streams are normally attached to "user_i/o" via the
"synonym" module as illustrated in Figure 3a, i.e. , they are made
equivalent to "user_i/o". Since at present most programs that perform I/O
intended to do so with the user's console, the stream names "user_output"
and "user_input" are the ones used in calls-to the I/O System in these
programs. This illustrates one of the important purposes of the "synonym"
DIM, to permit the manipulation of stream attachments without having to
attach and detach physical devices. The streams "user_input" and
"user_output" could normally be attached directly to the user's console
as shown in Figure 3b. However, this would force the console to be
detached whenever these streams were attached to some other device.
Detachment and subsequent reattachment implies that certain physical
hardware action has been taken with regard to the device. In the use of a
console this might include termination of communication with the console
and subsequently having to reestablish this communication. It would not
be difficult to indicate to the DIM to keep the device active, however,
the use of synonyms is more straightforward and makes more visible the
states of various devices, i.e., if they are attached they are active. In
other words, synonyms are an easy, efficient method of changing the
binding of streams to devices. Because of this use of synonyms the
"synonym" DIM has been highly optimized for the simple switching
described above.

On 2024-02-20, Spiros Bousbouras <spibou@gmail.com> wrote:
> And how is this different from what I wrote in my opening post , namely
>
> .... that is not a generalized synonym stream to any of the standard I/O
> customization variables but that might be a generalized synonym stream to
> the value of some implementation defined I/O customization variable.

I wrote with the objective that my written understanding not be
different from what the above means. If you also find that so, it
increases my confidence.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Alan Bawden <alan@csail.mit.edu> writes:

> I no longer remember why we designed this whole synonym stream thing.

[ ... ]

bivalent streams are useful.

"In addition, SBCL supports various extensions of ANSI Common Lisp
streams:

*Bivalent Streams*
A type of stream that can read and write both ‘character’ and
‘(unsigned-byte 8)’ values.

> I'm not aware of any modern system where I/O has this feature.

POSIX man dup

> I would be interested to know of any place that _does_ use synonym

I use the following for type 1 font dissasembler. I do not have the code
right now, but bivalent streams make it much easier to
read-char/read-byte.

;;
;;; Macros

(defmacro with-open-file-stream (direction type options &body body)
`(with-open-file
(,@options :direction ,direction :element-type ,type)
,@body))

(defmacro with-binary-input-stream (options &body forms)
`(with-open-file-stream :input '(unsigned-byte 8) ,options ,@forms))

(defmacro with-ascii-input-stream (options &body forms)
`(with-open-file-stream :input 'character ,options ,@forms))

(defmacro with-ascii-output-stream (options &body forms)
`(with-open-file-stream :output 'character ,options ,@forms))

(defmacro with-binary-output-stream (options &body forms)
`(with-open-file-stream :output '(unsigned-byte 8) ,options ,@forms))

> streams to solve some real problem.

i do not have real problems.

> - Alan

steve

steve <sgonedes1977@gmail.com> writes:

Alan Bawden <alan@csail.mit.edu> writes:

> I no longer remember why we designed this whole synonym stream thing.

[ ... ]

bivalent streams are useful.

"In addition, SBCL supports various extensions of ANSI Common Lisp
streams:

*Bivalent Streams*
A type of stream that can read and write both ‘character’ and
‘(unsigned-byte 8)’ values.

I don't see any connection with synonym streams here.

> I'm not aware of any modern system where I/O has this feature.

POSIX man dup

This does not make a synonym in the sense that Common Lisp is using the
word. If it made a synonym (in the Common Lisp sense) then after:

old = open("old_file", O_RDONLY);
new = open("new_file", O_RDONLY);
fd = dup(old);
dup2(new, old);

it would be the case that reading from FD would read from "new_file".
But if you try it, you will find that FD is still reading from "old_file".

> I would be interested to know of any place that _does_ use synonym

I use the following for type 1 font dissasembler. I do not have the code
right now, but bivalent streams make it much easier to
read-char/read-byte.

The code you included isn't using synonym streams.

I think you haven't fully internalized what a weird feature synonym
streams really are. Its easy to breeze through the documentation and
think that a synonym stream is just a way to duplicate a stream. But
it's more than that: The new stream follows the _current_ value of a
dynamic variable.

- Alan

On Sun, 14 Apr 2024 11:36:11 -0400, steve wrote:

> *Bivalent Streams*
> A type of stream that can read and write both ‘character’ and
> ‘(unsigned-byte 8)’ values.

How is that supposed to work, exactly? Is each stream item tagged in some
way to identify it as a “character” versus an “unsigned-byte 8”?

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Sun, 14 Apr 2024 11:36:11 -0400, steve wrote:
>
< > *Bivalent Streams*
< > A type of stream that can read and write both ‘character’ and
< > ‘(unsigned-byte 8)’ values.
>
> How is that supposed to work, exactly? Is each stream item tagged in some
> way to identify it as a “character” versus an “unsigned-byte 8”?

I don't have any code at the moment - you could use 'base-char which
includes

(with-open-file (out "/home/steve/file.txt" :direction :output :element-type 'base-char :if-exists :overwrite)
(write-string "this" out)
(terpri out)
(write out :stream out))
#<SB-SYS:FD-STREAM for "file /home/steve/file.txt" {1002E2A943}>
CL-USER>

File :
this
#<SB-SYS:FD-STREAM for "file /home/steve/file.txt" {1002E2A943}>

hope this helps...