The whole Channel thing

[chris hermansen]

Jose and list,

On Sun, Feb 8, 2026 at 6:32 PM Jose E. Marchesi <jemarch@gnu.org> wrote:

>
> > 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 :)
>
> If I had to bet on your idea or mine, I would bet on yours.  So what I
need to do, instead of arguing with you from a point of ignorance (because
I have this ignorant connection of Channel to file descriptor), I need to
review what Mountbatten did in QAD.

I confess also I find the appearance of Cover in van Vliet, with no obvious
explanation for it, a point of confusion.

Please grant me some time to read and think this over while looking deeper.

-- 
Chris Hermansen · clhermansen "at" gmail "dot" com

C'est ma façon de parler.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/algol68/attachments/20260208/e804f5ae/attachment-0001.htm>