The whole Channel thing

[Jose E. Marchesi]

> Jose and list,
>
> On Sun, Feb 8, 2026, 16:07 Jose E. Marchesi <jemarch@gnu.org> wrote:
>
>>
>> > Jose and list,
>> >
>> > On Sat, Feb 7, 2026 at 4:13 PM Jose E. Marchesi <jemarch@gnu.org> wrote:
>> >
>> >>
>> >> For me, I found the notion "a channel represents a physical device"
>> >> confusing until I realized it should not be understood as "a physical
>> >> device is represented by a single channel".
>> >>
>> >> I look at channels as ways to acccess books in physical devices, or
>> >> "modes" of access.
>> >>
>> >> For example,
>> >>
>> >>    stand_in_channel
>> >>    stand_back_channel
>> >>    stand_out_channel
>> >>
>> >> are all channels giving access to the same physical device: the
>> >> _filestore_.  In POSIX systems that is the hierarchy of filesystem
>> >> rooted at / and covers books like actual files stored in a filesystem on
>> >> some partition, character devices, /proc, etc.
>> >>
>> >> Using stand_in_channel, stand_back_channel and stand_out_channel
>> >> determines then not only the physical device (the filestore in all three
>> >> cases) but the "mode" of accessing the desired book: in read-only mode,
>> >> in read-write mode, in write-only mode.
>> >>
>> >> The idfs used in all three channels are filestore names, i.e. file paths
>> >> such as /foo/bar, /dev/null or `foo.o'.
>> >>
>> >> Then, you can have other channels that represent othe physical devices
>> >> that are not the filestore.  The collection in QAD is very interesting:
>> >>
>> >> stand_env_channel provides access to the environment of the runnign
>> >> process, which is _not_ the filestore.  The represented physical device
>> >> is the auxv array passed to _start by the kernel, and having it as a
>> >> channel allows to transput on the auxv array entreis (these are the
>> >> books) using the same interface than to files in the filestore.  The
>> >> idfs in this case are the names of the enviroment variables, PATH, HOME,
>> >> etc.
>> >>
>> >> A www_channel could represent the WWW.  The books would be the URIs you
>> >> use in http get and post operations.
>> >>
>> >> etc etc
>> >>
>> >> I think it is a nice abstraction.  Transput means interchanging data
>> >> with all sort of "external" devices, and not everythig is the filestore,
>> >> not even in Unix.
>> >>
>> >
>> > I like the eloquence of your argument and the points you make.  Just a
>> few
>> > minor comments:
>> >
>> > - the environment is in fact available in the filesystem, at least in
>> > Linux, at /proc/PID/environ; I have no idea whether writing to it is
>> > effective in some way or the other;
>>
>> I have never tried to write these files.  C programs use getenv/setenv.
>>
>
> I'm not advocating that! Just mentioning that Linux at least manifests the
> environment there.
>
>
>> > - in terms of handling something like web content, maybe a productive
>> line
>> > of thinking could consider the idf as a URI? which would open interesting
>> > avenues for exploration of other protocols than http and https;
>>
>> Yes, definitely.
>>
>
> Cool!
>
>>
>> > - in terms of "not everything is a file", in Plan 9 everything is in
>> fact a
>> > file; I'm not suggesting that we should retarget to Plan 9 however.
>> >
>> > Anyway, given your two sets of comments, and also those by Paul Leyland
>> > (separate), looking to QAD for additional guidance (beyond van Vliet) is
>> > good, and I think that's very helpful.
>> >
>> > Also, for the time being at least, it's reasonable to expect the standard
>> > prelude to define all necessary channels.
>> >
>> > And finally, for a first cut at things, a reasonable set of channels to
>> > provide is:
>> >
>> > - stand_in_channel; (read only)
>> > - stand_out_channel; (write only)
>> > - stand_back_channel; (read or write)
>> > - stand_err_channel; (write only)
>> >
>> > Any objections?
>>
>> Why stand_err_channel?
>>
>> I would expect standerr to be a standard File opened through
>> stand_out_channel...
>>
>
> I suppose this goes back to an earlier conversation we had here where IIRC
> I proposed that
>
> Algol68 File <-> stdio FILE
> Algol68 Channel <-> o/a file descriptor
> Algol68 Book <-> o/s file
>
> More or less anyway.
>
> Plus I'm probably missing it but I don't see how to redirect standout and
> standerr to two physically different places without two different channels.

I don't understand why a channel would correspond to a POSIX file
descriptor.  I would say the POSIX file descriptor belongs to the Algol
68 File, in the same way the stdio FILE contains somewhere the
underlying POSIX file descriptor.

When you open a File you specify a Channel:

  proc open = (ref File f, string idf, Channel chan) int

Inside `open' some of the characteristics of the Channel get copied into
the file.  In QAD these these characteristics are:

  - The BOOKTYPE of channel, which defines the permissions allowed in
    the opened File: get_possible, put_possible, etc.

  - The SYSPROCS of the channel, which are the procedures implementing
    the access to the books in the physical device.

Then, still inside `open', the File itself is passed to the `open'
procedure in SYSPROCS, which will do the posix open and install the
resulting POSIX file descriptor in the File.

The Channel disappears from the picture once the File has been opened.

Or that's how I understand it anyway :)