Ben Rudiak-Gould
fileRead can be implemented in terms of OS primitives,
Only if they already support reading from a fixed offset (like pread). I'm not sure if we can rely on something like this being always available, or whether it should be emulated using lseek which is safe only as long as we are the only process using the given open file. pread requires that the file is seekable, which means that it can't be used for all file handles: not for pipes, sockets, terminals nor various other devices.
and it's easy enough to implement a thread-safe seek/read interface on top of it.
Not if it must cooperate with other processes, and you *do* want to set a file position before running another program with redirected standard I/O. In this case it's not enough that you set a private Haskell variable holding its logical file position - you must perform the lseek syscall. Doing something differently than everybody else has a risk of limited interoperability, even if the new way is "better", and thus must be carefully evaluated to check whether all lost functionality is unimportant enough to lose. BTW, on Unix sockets and files are the same, but probably not on Windows. I don't know details about WinAPI. I know that basic file I/O uses HANDLEs, winsock uses ints which emulate Unix descriptors; what I don't know is whether you can also use HANDLEs for sockets (perhaps each winsock fd has an associated HANDLE with easy translation in both directions? or is there another API for sockets on HANDLEs?) and how do you perform redirection of standard I/O, in terms of HANDLEs or what - in particular I don't know whether you can redirect standard I/O to a socket. How should Haskell view this? I mean that on Unix it should somehow make files and sockets interchangeable, in order to support I/O redirection for programs being run; but it's not easy if you use completely different interfaces for files and sockets, as the streams proposal seems to do. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/