Re: PROPOSAL: add tryFdSeek to unix

On 6/29/11 1:44 AM, Bryan O'Sullivan wrote:
On Tue, Jun 28, 2011 at 5:15 PM, wren ng thornton
wrote: I'd like to propose adding a variant of fdSeek which returns errors directly instead of throwing an exception.
Why wouldn't you just wrap it in Control.Exception.try instead? And what's so special about seeking that suggests that it needs an alternate entry point?
(In other words, I'm opposed to this proposal.)
Why should it be wrapped? Why not have the error throwing variants be wrappers that case match against the Either? There's nothing special about seeking, per se. But not everyone is enamored of the exception system. In particular, libraries like iteratee already have their own FFI bindings in order to work around this limitation with the unix library. You'd have to ask John Lato and Oleg whether it is more because of performance issues or philosophical/linguistic issues. The point is, there are people already not using unix because of this. And, as mentioned in the proposal, there _is_ nothing special about seeking; the same API is being provided by unix-bytestring for reading and writing. The only reason for proposing this to unix is because System.Posix.IO is the appropriate home, and putting it there instead of another module will minimize transition issues once unix-bytestring is (eventually) rolled into unix. -- Live well, ~wren

On Wed, Jun 29, 2011 at 8:59 AM, wren ng thornton
Why should it be wrapped?
Because an error from seek is an exceptional condition, and we know from long experience in numerous languages that people are very good at forgetting to check for exceptional conditions.
participants (2)
-
Bryan O'Sullivan
-
wren ng thornton