On Tue, Nov 08, 2011 at 01:07:23PM +0000, Duncan Coutts wrote:
We should take the same approach with openFile. Currently we have:
openFile :: FilePath -> IOMode -> IO Handle
I suggest changing the IOMode for a record of options which would include the IO mode (read/write/read-write/etc), and other things like file locking, default create permissions, create exclusive etc. Again, we'd use a default value and override extra options as necessary.
I've just reread the thread, and I think the best way forwards would be to make the original proposed change now, and for the above change to be proposed separately. By making the proposed change now, we eliminate the unexpected locking behaviour, and the API effectively doesn't change (I say "effectively", because the semantics are obviously different, but I doubt anyone is relying on getting an exception due to the Haskell locking). We can separately, perhaps even initially in a separate library, think about what the best replacement design is. For example, we may wish to pass openFile a lock and unlock function, rather than just having a Bool to control whether it uses its own internal locking. Either way, I think we ought to have access to base's locking functions, so that we can use them with FFI imports that do file IO. As Duncan said, if any supporters of the original proposal disagree with this approach, please speak up! Thanks Ian