Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.lisp > #59265 > unrolled thread

CLHS on *DEBUG-IO* and others

Back to article view | Back to comp.lang.lisp

Contents

  CLHS on *DEBUG-IO* and others Spiros Bousbouras <spibou@gmail.com> - 2024-02-17 14:08 +0000
    Re: CLHS on *DEBUG-IO* and others Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-17 16:34 +0000
    Re: CLHS on *DEBUG-IO* and others Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-18 22:06 +0000
      Re: CLHS on *DEBUG-IO* and others Spiros Bousbouras <spibou@gmail.com> - 2024-02-19 12:09 +0000
        Re: CLHS on *DEBUG-IO* and others Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-19 17:40 +0000
          Synonym Streams Alan Bawden <alan@csail.mit.edu> - 2024-02-19 17:06 -0500
            Re: Synonym Streams Spiros Bousbouras <spibou@gmail.com> - 2024-02-20 17:54 +0000
            Re: Synonym Streams steve <sgonedes1977@gmail.com> - 2024-04-14 11:36 -0400
              Re: Synonym Streams Alan Bawden <alan@csail.mit.edu> - 2024-04-14 18:49 -0400
              Re: Synonym Streams Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-04-15 00:49 +0000
                Re: Synonym Streams steve <sgonedes1977@gmail.com> - 2024-04-19 13:44 -0400
          Re: CLHS on *DEBUG-IO* and others Spiros Bousbouras <spibou@gmail.com> - 2024-02-20 17:47 +0000
            Re: CLHS on *DEBUG-IO* and others Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-20 18:18 +0000

#59265 — CLHS on *DEBUG-IO* and others

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.

[toc] | [next] | [standalone]

#59266

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

[toc] | [prev] | [next] | [standalone]

#59331

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”?

[toc] | [prev] | [next] | [standalone]

#59346

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.

[toc] | [prev] | [next] | [standalone]

#59350

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

[toc] | [prev] | [next] | [standalone]

#59354 — Synonym Streams

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

[toc] | [prev] | [next] | [standalone]

#59365 — Re: Synonym Streams

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.

[toc] | [prev] | [next] | [standalone]

#59524 — Re: Synonym Streams

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

[toc] | [prev] | [next] | [standalone]

#59525 — Re: Synonym Streams

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

[toc] | [prev] | [next] | [standalone]

#59526 — Re: Synonym Streams

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”?

[toc] | [prev] | [next] | [standalone]

#59552 — Re: Synonym Streams

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...

[toc] | [prev] | [next] | [standalone]

#59364

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

[toc] | [prev] | [next] | [standalone]

#59366

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.lisp

csiph-web