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