The whole Channel thing

[Jose E. Marchesi]

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

Heh I am also pretty much ignorant.  We are just trying to make a sense
of these things :)

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

I looked at van Vliet's "ALGOL 68 Transput Part I: Historical review and
discussion of the implementation model" and indeed there is no
explanation about that.

By looking at Part II (the code):

MODE FILE = STRUCT(
  REF COVER #?# cover,
  REF REF FORMATLIST #?# piece,
  CHARBAG #?# term,
  PROC (REF FILE, CHAR) VOID #?# write char,
  PROC (REF FILE, BINCHAR) VOID #?# write bin char,
  PROC (REF FILE, REF CHAR) BOOL #?# read char,
  PROC (REF FILE, REF BINCHAR) VOID #?# read bin char,
  PROC (REF FILE) BOOL #?# logical file mended, #?# physical file mended,
       #?# page mended, #?# line mended, #?# format mended,
       #?# value error mended,
  PROC (REF FILE, REF CHAR) BOOL #?# char error mended);

MODE #?# COVER = STRUCT(
  BOOK book,
  CHANNEL chan,
  BUFFER buffer,
  REF [] [] [] CHAR text, # for associated files only #
  POS cpos,
  INT c of lpos,
  STATUS status,
  INT char bound,
  POSSIBLES possibles,
  PROC (REF FILE) VOID init buffer, write buffer, do newline,
       do newpage, do reset,
  PROC (REF FILE, INT, INT, INT) VOID do set);

I would say cover is the part of the File's attributes that are relevant
to the opened book: the buffer, a pointer to the atual book contents in
case of associated files, the current position, etc.

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

Sure, and thanks!  You are the one doing the work.  I'm peanuts gallery.