Proposal for a new I/O library design

[Stefan Karrmann]

Ben Rudiak-Gould (Sun, Jul 27, 2003 at 09:35:41PM -0700): 
> > module System.ProposedNewIOModel (...) where
> 
> I assume that all I/O occurs in terms of octets. I think that this
> holds
> true of every platform on which Haskell is implemented or is likely to
> be
> implemented.
> 
> > type Octet = Word8 

If it should be really generall the base type should be Bool.

> File offsets are 64 bits on all platforms. This model never uses
> negative
> offsets, so there's no need for a signed type. (But perhaps it would
> be
> better to use one anyway?) BlockLength should be something appropriate
> to
> the architecture's address space.
> 
> > type FilePos = Word64
> > type BlockLength = Int
> 
> type FilePos = Integer 
> type BlockLength = Integer 
> 
> > data File   -- abstract

I would prefer: 

data ImmutableStore   -- abstract
data MutableStore     -- abstract

A note about buffering:
Actually, current UNIX kernels do not support non-blocking descriptors;
they support non-blocking open files. Furthermore, many programs will
break if they encounter non-blocking mode. This means that you must not
[change blocking mode] for a descriptor inherited from another program.
                                See <http://cr.yp.to/lib/io.html>.

> A value of type InputStream or OutputStream represents an input or
> output
> stream: that is, an octet source or sink. Two InputStreams or
> OutputStreams compare equal iff reading/writing one also reads/writes
> the
> other.
>
> (Should I call these "ports" instead of "streams"? How about
> "OctetSource"
> and "OctetSink"?)
>
> > data InputStream    -- abstract
> > data OutputStream   -- abstract

Use

data OctetSource        -- abstract  (or BitSource, s.a.)
data OctetSink          -- abstract  (or BitSink, s.a.)

for octets (or bits/bools) and

data PacketSource       -- abstract
data PacketSink         -- abstract

to send complete packets of data by the latter.

Sincerly,
--
Stefan