The whole Channel thing

[chris hermansen]

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.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/algol68/attachments/20260208/b839b79c/attachment.htm>