Stream designators are conveniences when creating source code. It makes for compact expression.

BUT: can (or should?) stream designators be used deeper down, as entities resolved during actual evaluation?

Specifically wondering about SYNONYM-STREAM.

The [dynamic] variable of such a stream holds the value on which an operation is to be performed.

If that variable is bound to an actual stream object, then everything seems well-defined.

But if that variable is bound to a STREAM DESIGNATOR, is this well-defined? We have for instance the ambiguity of designator NIL (input vs output).

So:
(1) are stream designators formally acceptable as values of the variable for a SYNONYM-STREAM?

(2) if they are not acceptable, do implementations conform to this requirement in a consistent manner?

(3) if they are acceptable, should one avoid using designators for SYNONYM-STREAMs?

(4) are there informative examples that illustrate the pros and cons of using stream designators in the context of SYNONYM-STREAMs?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-09-02, redsk...@gmail.com <redsky1066@gmail.com> wrote:

Stream designators are conveniences when creating source code. It makes for compact expression.

BUT: can (or should?) stream designators be used deeper down, as entities resolved during actual evaluation?

Since, e.g. format is a function, it takes t and nil as an argument value. Stream designators
are actual values and not just some macro-time syntax.

Specifically wondering about SYNONYM-STREAM.

The [dynamic] variable of such a stream holds the value on which an operation is to be performed.

The definition of synonym streams doesn't mention stream designators.
The dynamic variable held by the synonym stream is described as having
a stream value, not a stream designator value.

In fact, stream designators are not mentioned in the Streams section of the spec; only in the Printer setion.

Thus, write takes a stream designator; write-byte doesn't.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, 2 September 2023 at 17:13:37 UTC+2, Kaz Kylheku wrote:

On 2023-09-02, redsk...@gmail.com <redsk...@gmail.com> wrote:

Stream designators are conveniences when creating source code. It makes for compact expression.
[snip]

The definition of synonym streams doesn't mention stream designators.
The dynamic variable held by the synonym stream is described as having
a stream value, not a stream designator value.
[snip]
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazi...@mstdn.ca

What you describe is what I would say is the most natural way of understanding this topic. That is, the variable in a SYNONYM-STREAM must have STREAMs as values. Simplifies the dynamics, and eliminates some potential problematic situations.

But as to the object designating a stream in FORMAT, that is, strictly speaking, not a stream designator. Because, as stream designators both T and NIL have a "usage-independent" specific denotations. Use of NIL in FORMAT does not conform with NIL as a *
stream* *designator*, as it has a very specific meaning for FORMAT.

So for FORMAT, the denotation of the stream indicator is "usage-dependent", and this stream indicator is resolved to a stream in a very unique way.

This anomaly for FORMAT may be just the remnants of an historical accident, where providers of Common Lisp implementations were not willing to compromise during the standardization process, so we were left with yet another exception in the CL standard.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)