Proposal for a new I/O library design

[Simon Marlow]

=20
> But the upshot of the discussion here is that there's no way=20
> to implement
> a well-behaved File abstraction on Win32 or Posix, so people are just
> going to have to continue writing insecure programs on a=20
> less-elegant API.
> Stop me if I start to sound bitter. :-)

I'm more familiar with Unix than Win32, but it seems to me that if
you're willing to accept that the File abstraction includes access
rights, then you can have Files with the identity properties you want.
Equality can even ignore the access rights.

You're right that dCreateFileEntry cannot be implemented on Unix,
however.  I think this is a killer for the Directory abstraction.

I think there is merit in other parts of the proposal, though.
Separating streams from the underlying File object seems worthwhile:

  - You can have several streams open on a single File

  - Streams make sense for other underlying objects (eg. Sockets)

  - You don't have to pretend that all streams are files
    (eg. stdout, stdin and stderr are just streams)

And separating Input and Output streams also looks worthwhile - as the
implemntor of GHC's IO library I know this would simplify things quite a
bit, and to me it also looks nicer from the programmer's perspective.

Cheers,
	Simon