RE: Channel concept instead of simple Files

[acken@informatik.uni-kl.de]

>  From: Sander van der Wal <svdwal@xs4all.nl>
>  Date: Fri, 12 Jan 1996 17:23:56 +0100
>  ...
>  > Unix, and AFAIK AmigaOS, simply spend the file descriptor (stream,
>  > channel, or whatever) additional attributes and/or prevent a function
>  > that needs a specific feature from being used.  For example the Unix
>  > pipes and FIFOs don't allow lseek() and make it return with an error
>  > code.  A simple solution to this problem is to add an "is
>  > positionable" flag to the channel, similar to the "is readable" and
>  > "is writable" flags.
>  
>  RISC OS does something similar with the file descriptor. Unix really
>  has a large influence ;-).
>  I find the use of a 'is positionable' flag a bit of a hack.
>  If there are two kinds of channels, a positionable one and a sequential 
>  one, I can immediately deduct some properties of the algorithm that 
>  uses a paricular kind of channel. Take for instance a backend for ooc:
>  if the channel is sequential, I immediately know that either the code
>  generator is sequential too, or that it buffers the code.  
>   
We could replace the type Channel by SeqChannel (only allowing
sequential read/write) and PosChannel (positionable channel; ugly
naming scheme, though).  Where PosChannel is an extension of
SeqChannel.  I don't want to split the Reader/Writer into ones that
have SetPos and ones that don't, mainly because the tb procs
associated with channels, like
    PROCEDURE (c: SeqChannel) NewReader(): Reader;
    PROCEDURE (c: PosChannel) NewReader(): Reader;
can only have a single formal result type.  So you can detect from the
channel if SetPos works, but not (directly) from the reader/writer.

-- mva