Raw I/O library proposal, second (more pragmatic) draft

[Simon Marlow]

=20
> On Wed, 6 Aug 2003, Simon Marlow wrote:
>=20
> > -- TODO: what if a file refers to a FIFO?
> > fileInputStream  :: File -> FileOffset -> IO FileInputStream
> > fileOutputStream :: File -> FileOffset -> IO FileOutputStream
>=20
> Part of my original design was that File values always refer to
> random-access files. Most of the operations on Files make no=20
> sense with
> anything else. openFile might succeed on something like /dev/kmem
> (although I'm not convinced that this is type-safe :-), but=20
> to open a FIFO
> you had to use openXputStream instead. This avoids the=20
> questions raised by
> using the functions above on non-seekable handles (What would the
> FileOffset argument mean? and What happens if you put more=20
> than one input
> or output stream on the same FIFO?).

I agree.  Should we provide

  openInputStream  :: FilePath -> IO InputStream
  openOutputStream :: FilePath -> IO OutputStream

what if you want to open both streams?  You have a race condition, so we
must provide=20

  openInputOutputStream :: FilePath -> IO (InputStream,OutputStream)

Furthermore, we have to discourage the use of openFile + fileInputStream
in favour of openInputSream, because the former combination doesn't work
with FIFOs and special files (this seems a bit fragile, but I'm not sure
what to do about it).

What mechanism should underly these functions?  Should it be

  data FilesystemObject
      =3D FSFile File
      | FSFIFO FIFO
      | FSTerminal Terminal
      | FSDevice Device

  openFilesytemObject :: FilePath -> IO FilesystemObject

Now perhaps we're getting too Unix specific.  I don't have a clear idea
for how to proceed.  Suggestions?

Cheers,
	Simon