The whole Channel thing

[Paul Leyland]

> 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 also think it would be a Good Thing to follow this approach. Please 
excuse my bad language but I would hope that the Algol68 would be useful 
on MS Windows, and there not just under WSL. Being perhaps unduly 
cynical, it would likely increase the market size significantly.

That said, I know the Perl developers had immense difficulty porting to 
Windows and even today I occasionally get bitten when using software 
written under the assumption that COM, LPT, etc, are perfectly good 
names for regular files.I really hope we don't get stuck in a rabbit 
hole hidden under a layer of quicksand.

Paul