On Thu, 26 Mar 2009, Xiao-Yong Jin wrote:

So I have another question. Is the following function safe and legitimate?

...

safeDiv :: (Exception e, Integral a) => a -> a -> Either e a safeDiv x y = unsafePerformIO . try . evaluate $ div x y

I believe it should be okay to use this 'safeDiv'. What do

I think that question is wrong way around. The real question is, why do you want to solve your problem using unsafePerformIO?

On Thu, 2009-03-26 at 14:23 -0400, Xiao-Yong Jin wrote:

Henning Thielemann writes:

...

On Thu, 26 Mar 2009, Xiao-Yong Jin wrote:

...

So I have another question. Is the following function safe and legitimate?

...

safeDiv :: (Exception e, Integral a) => a -> a -> Either e a safeDiv x y = unsafePerformIO . try . evaluate $ div x y

I believe it should be okay to use this 'safeDiv'. What do

I think that question is wrong way around. The real question is, why do you want to solve your problem using unsafePerformIO?

I just want to know, from a theoretical point of view, whether this 'safeDiv' in above definition is the same as

...

safeDiv' :: (Exception e, Integral a) => a -> a -> Either e a safeDiv' _ 0 = Left e safeDiv' x y = Right $ div x y

You need some sort of type case here to make sure your first case matches only if e is the right type for divide-by-zero errors (too lazy to look it up atm). Alternatively, you could replace your type variable e with the actual exception type you want, here and in the unsafePerformIO version. Other than that, I think the imprecise exceptions paper guarantees that these two functions are equivalent (albeit unwisely: see below).

For the question why do I want to do that, I am not sure. I guess if the function which has an error call inside is provided by other library package, and I don't have a clear and easy way to tell whether the function will make the error call or not, it would be easy just to make a wrapper like that.

It might be easy, but if you didn't have a lot of insight into the function's behavior, then it would be difficult to tell whether it's really going to call error or whether it's going to go off into an infinite loop. (Consider the (slow) definition x ^ n | n == 0 = 1 | n < 0 = error "Negative exponents require ^^" | otherwise = x * x ^ (n - 1) Now consider what happens if the library function forgets the second case. Your wrapper isn't safe anymore!) I can see only two cases where a library function could call error sometimes, and you wouldn't have a good feel for when: a) The function is calling error on exceptions. You should bug the library author to put the function into an exception monad instead. Devil-may-care users can use either (error . show) id to turn exceptions into errors. b) The function has explicit pre-conditions, which you don't understand. You shouldn't pass arguments to a function that violate its pre-conditions (ever!); if you don't understand those preconditions well enough to test them in Haskell code, you might not understand them well enough to make sure your code is calling the function correctly. So you might want to study the preconditions a little more.

It's also a possible situation that I don't know how to test the input to a foreign function call.

FFI calls cannot throw Haskell exceptions. jcc

On Thu, 2009-03-26 at 21:57 -0400, wren ng thornton wrote:

Jonathan Cast wrote:

...

Xiao-Yong Jin wrote:

...

...

Xiao-Yong Jin wrote:

...

So I have another question. Is the following function safe and legitimate?

...

safeDiv :: (Exception e, Integral a) => a -> a -> Either e a safeDiv x y = unsafePerformIO . try . evaluate $ div x y

...

safeDiv' :: (Exception e, Integral a) => a -> a -> Either e a safeDiv' _ 0 = Left e safeDiv' x y = Right $ div x y

[...] Other than that, I think the imprecise exceptions paper guarantees that these two functions are equivalent (albeit unwisely: see below).

I don't think so. The evaluation of x and y may throw errors before we get around to div.

Sure. Which also points out that the original safeDiv wasn't actually safe, since there's no guarantee of what evaluate will do with x and y. (Actually, there's not much guarantee of what evaluate does anyway --- just that any errors in e's definition get turned into exceptions by the time evaluate e finishes running, or don't turn into exceptions at all).

* safeDiv' will evaluate y (to pattern match against 0) and may return an error, e, whereas safeDiv will return Left e if div is strict in y.

* safeDiv' postpones evaluating x and so may return Right e, whereas safeDiv will return Left e if div is strict in x.

jcc

On Fri, 2009-03-27 at 12:24 +0000, Chris Kuklewicz wrote:

Jonathan Cast wrote:

...

Sure. Which also points out that the original safeDiv wasn't actually safe, since there's no guarantee of what evaluate will do with x and y. (Actually, there's not much guarantee of what evaluate does anyway --- just that any errors in e's definition get turned into exceptions by the time evaluate e finishes running, or don't turn into exceptions at all).

That is not true if you mean "any errors" as "any and all errors".

No, that's not what I mean. I just couldn't think of a good phrasing for `errors that would prevent e from being evaluated to HNF'. Which is still a lousy phrasing. jcc

Quoth John Lato ,

An exception is caused by some sort of interaction with the run-time system (frequently a hardware issue). The programmer typically can't check for these in advance, but can only attempt to recover after they've happened.

An error is some sort of bug that should be fixed by the programmer.

I have never felt that I really understood that one. What about invalid inputs? Say someone encounters a disk full error, and the resulting partly written file is now unreadable data for its intended application because of an invalid file encoding? Is that an exception, or a bug that should be fixed? My guess is that you'll say it's a bug, i.e., that application's file decoding result should be an Either type that anticipates that the file encoding may be invalid. I will also guess if the file is unreadable because of an external I/O problem like no read access to file or filesystem, you would similarly expect this to be treated like that - I mean, ideally, e.g., hGetLine :: Handle -> IO (Either IOError String) Does that make sense so far? Donn

Jonathan Cast schrieb:

...

i.e., that application's file decoding result should be an Either type that anticipates that the file encoding may be invalid.

This is pretty standard, I thought. Do people write Haskell file input methods that are undefined (`throw exceptions') on invalid inputs (e.g., do people use read to parse input from users or the file system[1])?

With case reads str of [(x, "")] -> Just x _ -> Nothing you are safe. (I think it's now available as maybeRead.) In general, relying on a well-formed input file is an error. However, if your program detects a format error in file input, it could throw an exception. But this means that your program must be prepared for these problems.

...

I will also guess if the file is unreadable because of an external I/O problem like no read access to file or filesystem, you would similarly expect this to be treated like that - I mean, ideally, e.g., hGetLine :: Handle -> IO (Either IOError String)

IO is an exception monad already. I don't think there's an objection to throwing exceptions with throwIO and catching them in IO; my objection, at least, is to designing your program to throw exceptions from (ostensibly...) *pure* code and catch those in IO, in a live environment.

Actually, I really object to have exception handling built into IO monad. Especially with extensible-exceptions package you can hide which kinds of exceptions can occur in a piece of code, which is a bad thing. When it comes to lazy I/O, which is problematic in itself, it is better to have explicit exceptions (i.e. IO (Either IOError String)) on top of exception-free IO. See the recent thread on safe lazy I/O: http://www.haskell.org/pipermail/haskell-cafe/2009-March/058205.html

On Sat, 2009-03-28 at 01:27 +0100, Henning Thielemann wrote:

Jonathan Cast schrieb:

...

...

i.e., that application's file decoding result should be an Either type that anticipates that the file encoding may be invalid.

This is pretty standard, I thought. Do people write Haskell file input methods that are undefined (`throw exceptions') on invalid inputs (e.g., do people use read to parse input from users or the file system[1])?

With

case reads str of [(x, "")] -> Just x _ -> Nothing

you are safe. (I think it's now available as maybeRead.)

Hmm, hoogle doesn't know that name.

In general, relying on a well-formed input file is an error. However, if your program detects a format error in file input, it could throw an exception. But this means that your program must be prepared for these problems.

Right.

...

...

I will also guess if the file is unreadable because of an external I/O problem like no read access to file or filesystem, you would similarly expect this to be treated like that - I mean, ideally, e.g., hGetLine :: Handle -> IO (Either IOError String)

IO is an exception monad already. I don't think there's an objection to throwing exceptions with throwIO and catching them in IO; my objection, at least, is to designing your program to throw exceptions from (ostensibly...) *pure* code and catch those in IO, in a live environment.

Actually, I really object to have exception handling built into IO monad. Especially with extensible-exceptions package you can hide which kinds of exceptions can occur in a piece of code, which is a bad thing. When it comes to lazy I/O, which is problematic in itself, it is better to have explicit exceptions (i.e. IO (Either IOError String)) on top of exception-free IO. See the recent thread on safe lazy I/O: http://www.haskell.org/pipermail/haskell-cafe/2009-March/058205.html

Yi's new parsing library (just finished the paper a couple days ago) seems quite appropriate to a lazy IO library; for that library, partial grammars are errors anyway, so the issue doesn't really arise. If you want IO failure/parsing failure handling in lazy IO, my preference would be for a separate failure-handling hook (which can throw an asynchronous exception if needed) rather than for any kind of synchronous exception mechanism per se. There's really not much you can do, except tell the user either `hey, that doesn't look like valid input!' or `sorry, the other side of the network connection disappeared', and hope the operator can correct the issue. I don't think it's really important to let the input processing (as opposed to parsing) code handle the situation specifically. jcc

On Sat, 28 Mar 2009, Ketil Malde wrote:

Jonathan Cast writes:

...

...

i.e., that application's file decoding result should be an Either type that anticipates that the file encoding may be invalid.

...

This is pretty standard, I thought. Do people write Haskell file input methods that are undefined (`throw exceptions') on invalid inputs (e.g., do people use read to parse input from users or the file system[1])?

I often write parsers that either run successfully, or abort with an exception. I could of course return an Either type, but that would mean the whole file would need to be parsed before any results could be returned at all - which is a showstopper for streaming processing of large files.

If you need a lazy parser with error reporting, I suggest Control.Monad.Exception.Asynchronous from the explicit-exception package.

Since at least my files are typically machine generated, a parse error is either a programmer error in my parser, a programmer error in the generating program, or an operator error (viz. the user running the program on a completely different file type).

That's no excuse. You can never rely on proper file formatting since the user alter the file while you process it, delete it, or remove the disk it is stored on.

On Fri, 2009-03-27 at 20:38 +0300, Gregory Petrosyan wrote:

On Fri, Mar 27, 2009 at 7:31 PM, Donn Cave wrote:

...

Quoth John Lato ,

...

An exception is caused by some sort of interaction with the run-time system (frequently a hardware issue). The programmer typically can't check for these in advance, but can only attempt to recover after they've happened.

An error is some sort of bug that should be fixed by the programmer.

I have never felt that I really understood that one.

Me too :-)

BTW, John, how often do you encounter _hardware_ issues compared to "errors"?

Can't speak for anyone else, but I usually encounter hardware issues just before I replace the hardware...

Is an "out of memory" thing an error or exception? You will say "exception, for sure", wouldn't you? :-)

No. GHC possesses an out-of-memory exception that (IIRC) it never throws, because it's simply not worth trying to recover from heap exhaustion. Maybe 20 years ago it was, but these days a program that manages to exhaust space is almost certainly either buggy or poorly optimized. An `error' is any condition where the correct response is for the programmer to change the source code :)

And if it is a result of applying known-to-be-very-memory-hungry algorithms to non-trivial input? Looks like programmer's error, doesn't it?

See above.

And I think I can provide lots of similar examples.

If there exists separation between errors and exceptions, it should be very strong and evident — otherwise "casual programmers" like myself will need to stare at the ceiling every time they write something to decide what suits best.

Protip: try pacing instead of staring at the ceiling. jcc

On Fri, 27 Mar 2009, Donn Cave wrote:

Quoth Jonathan Cast ,

...

An `error' is any condition where the correct response is for the programmer to change the source code :)

That's a broad category, that overlaps with conditions where there are one or more correct responses for the original program as well.

If I throw exceptions within the type system, using IO or whatever, and at some later time observe that I have caught one that would have been better handled closer to its source, for example. I've already technically satisfied my requirement, since everything is in an exception monad, but the exception is still a bug.

I don't understand this one.

Or if I catch an non-IO error using Control.Exception.catch (if I were using ghc), and take advantage of the opportunity to release locks, post various notices, etc. - I evidently have a bug, but I also may need to have a programmed response for it.

The usual example against clear separation of exceptions and errors is the web server which catches 'error's in order to keep running. However, the web server starts its parts as threads, and whenever one thread runs into an 'error', it is terminated, just like an external shell program, that terminates with a segmentation fault. So, yes an error might be turned into an exception, but these are rare cases. In general it is hard or impossible to correctly clean up after an error, because the error occured due to something that you as programmer didn't respect. The "error handler" could well make things worse by freeing memory that is already deallocated and so on.

Quoth Henning Thielemann ,

On Fri, 27 Mar 2009, Donn Cave wrote:

...

Quoth Jonathan Cast ,

...

An `error' is any condition where the correct response is for the programmer to change the source code :)

That's a broad category, that overlaps with conditions where there are one or more correct responses for the original program as well.

If I throw exceptions within the type system, using IO or whatever, and at some later time observe that I have caught one that would have been better handled closer to its source, for example. I've already technically satisfied my requirement, since everything is in an exception monad, but the exception is still a bug.

I don't understand this one.

A lame attempt to demonstrate that "condition where [a] correct response is to change the code" applies to too many cases to be useful. (And that there are no cases where [the only] correct response is to change the code.)

...

Or if I catch an non-IO error using Control.Exception.catch (if I were using ghc), and take advantage of the opportunity to release locks, post various notices, etc. - I evidently have a bug, but I also may need to have a programmed response for it.

The usual example against clear separation of exceptions and errors is the web server which catches 'error's in order to keep running. However, the web server starts its parts as threads, and whenever one thread runs into an 'error', it is terminated, just like an external shell program, that terminates with a segmentation fault. So, yes an error might be turned into an exception, but these are rare cases. In general it is hard or impossible to correctly clean up after an error, because the error occured due to something that you as programmer didn't respect. The "error handler" could well make things worse by freeing memory that is already deallocated and so on.

But you'd have to weigh that against the consequences of not continuing. I can certainly see the attraction of the exception monad treatment for anticipated errors. It might tend to obscure a central computation for the sake of handling a lot of weird little errors that may never actually be encountered, and doesn't it occasionally have a problem with making things strict that didn't already need to be? but at least it makes it easier to reason about the code in terms that include errors. And I'm using nhc98 lately, so no Control.Exception.catch for me, but if I had it, I'd use it, just like I wear a helmet when I ride my bicycle or motorcycle. Donn