August 2004 - Haskell-Cafe

Re: [Haskell-cafe] exceptions vs. Either
by MR K P SCHUPKE 05 Aug '04

05 Aug '04

>f (case xs of (x:_) -> x; [] -> error "whoops") -- direct style Yup, this is how I do it... I never use head! I like to pass failures back up to the level where some kind of sensible error message can be generated. In your example the error is no better than with 'head' - the point is a Nothing can be 'caught' outside of an IO monad. I would suggest using the type system as I said earlier so: toNonEmptyList :: [a] -> Maybe (NonEmpty a) toNonEmptyList (a0:_) = Just (NonEmpty a) toNonEmptyList _ = Nothing Then redefine head: head :: NonEmpty a -> a head (NonEmpty (a0:_)) = a0 Keean/

3 2

exceptions vs. Either
by Evan LaForge 04 Aug '04

04 Aug '04

Exceptions are convenient in that you can rely on libraries throwing them instead of prechecking for valid values yourself (for instance, why check that the argument to Char.digitToInt is valid if digitToInt does so already), and you don't have to modify a lot of function signatures. Unfortunately, in the face of lazy evaluation, they can get thrown in unexpected places. Even with Exception.evaluate, or code which is already explicitly sequenced in the IO monad, like "t <- Exception.evaluate (map Char.digitToInt ['a'..'g'])" an exception will only be thrown when you inspect the last element of 't'. (digitToInt confusingly accepts hex "digits"---shouldn't it be "higitToInt" then?). So it seems to me that if you are, say, checking input, the options are to handle exceptions from the checking code but expect them to come from the processing code, or decorate all checking code with Rights and Lefts. Problems with the first option are that checking code could also trigger some exceptions, and Prelude functions throw undescriptive errors like "user error" or low level ones like "refuted pattern match" and catching them over the entire program means you could stifle a lot of real errors. This implies that you have to make specific exceptions and convert Prelude and library exceptions into yours as low down as possible, which is cluttering but maybe not as cluttering as Either. Problems with the second option are many of the problems that lead to us wanting exceptions in the first place. Using Either seems much simpler and functional-friendly. So then, in what contexts are exceptions appropriate in haskell?

9 12

Re: [Haskell-cafe] exceptions vs. Either
by MR K P SCHUPKE 04 Aug '04

04 Aug '04

>No, I don't think so. I only want the bug to be reported I think preventing the bug using the type system if possible is a good idea... something that should be encouraged! >and not a "corner case" that should be "handled". So if the list depends on user input is not the empty list a corner case of the function on user input? >write small leaf functions like these with an implicit file/line This is a good idea - If I have given the impression I am opposed to it then I have not expressed myself very well. I just think where this can be avoided using the type system in the first place is an even better idea. Design by contract is the way forward for large complex systems, and where that contract can be expressed using the type system is a selling point for Haskell in such applications. >It seems difficult to generalize this, though. Again for read you can use "reads"... Sven Panne said: "reads" is probably what you are looking for: Prelude> (reads :: ReadS Integer) "" [] Prelude> (reads :: ReadS Integer) "a" [] Prelude> (reads :: ReadS Integer) "2" [(2,"")] Prelude> (reads :: ReadS Integer) "123blah" [(123,"blah")] Keean.

1 0

Re: [Haskell-cafe] exceptions vs. Either
by MR K P SCHUPKE 04 Aug '04

04 Aug '04

>Yes, in principle. But that means you still need to write more and >tedious code to deal with it. Just because code is tedious does not mean it is not necessary to handle all corner cases. A robust application does not fail when given unexpected input. >Are you going to discard lists in favor of tuples, Of course not... You can actually define constrained datatypes where the maximum length is a parameter of the type. Unfortunately in haskell because these values have to be at the type level we end up encoding them as Peano numbers... See Conor McBrides "Faking It" paper for some examples of how to do this. Also see Oleg, Ralf and My paper "Stronly Typed Heterogeneous Lists" to se how far you can get with these techniques (we define a heterogeneous list that can be constrained in many ways, including by length, or content type). I guess in a way you are nearly right as these techniques fundamentaly us binary products like (,) - but thats also exactly what any binary constructor including ':' is anyway... >The only difference is that I want to do it automatically My point was that you can manually label some functions, but to automatically do it for all functions is going to cause big stack space problems - think about recursive functions... or mutually recursive functions... Keean.

2 1

Re: [Haskell-cafe] exceptions vs. Either
by MR K P SCHUPKE 04 Aug '04

04 Aug '04

>Sometimes the qualification of an error changes while it is propagated. There was a discussion about this recently (on the ghc list I think)( The proposed (partial) solution is to use mapException: mapExceptionIO :: (Exception -> Exception) -> IO a -> IO a mapExceptionIO f io = Exception.catch io (\e -> throw $ f e) which would be used like: main = mapExceptionIO (\x -> ErrorCall $ showString "in main: " $ show x) $ do Exceptions can be thrown from anywhere, but can only be caught in the IO monad hence mapException must be in the IO monad. Map exception allows a kind of 'backtrace' allowing all functions in the call stack of a function which throws an exception to annotate the error message. Exceptions should only really be used for unpredictcable events, I find that the defintion of functions like head is lacking rigor... I would prefer to see: head :: [a] -> Maybe a head (a0:_) = Just a0 head _ = Nothing I think functions should only throw an exception if they are subject to the halting problem (the only way to tell if an algorith will fail is to run that algorith) - head and lots of other functions in the prelude are not subject to this, and in my opinion should really be returning Maybe... nobody said anything about me previous post about using the type system to have 'validated' types - does this mean everyone thinks its a good idea, or was it too off topic - too obvious? Keean.

4 3

Re: [Haskell-cafe] exceptions vs. Either
by MR K P SCHUPKE 04 Aug '04

04 Aug '04

>mins = map ((\(x:_)->x).sort) maybe what you meant was: case sort x of (x:_) -> ... do whatever with x ... _ -> ... do failure conition ... As I said, if you can _guarantee_ non failure I guess head is okay, but the fact that this thread started with the observation that the error produced by head is difficault to track dow n we must conclude that programmers make mistakes and cannot be trusted to make such guarantees .... Hence my suggestion to use the type system. Effectively the 'case' forms a guarantee of non-emtyness for the stuff in the case... but you cannot pass this guarantee into functions like 'head' Using the type system to encode such things allows this 'guarantee' to be passed into functions... Keean.

1 0

Re: [Haskell-cafe] exceptions vs. Either
by MR K P SCHUPKE 04 Aug '04

04 Aug '04

>As for head, I think it's fine that it throws an error because it is >specified to be defined for only non-empty lists. But surely it is better to encode this fact in the type system by useing a separate type for non-empty lists. >Argh, no! Violating the precondition of head is a bug in the caller, >I want it to crash, Again by encoding this at the type level the compiler can guarantee that that it is not going to crash or return a compile time error... also by forcing the programmer to deliberatly cast to a non-empty list you make explicit the 'non-emptyness'... also the type signature of head contains the 'contract' that the list must be non empty. >A mechanism for a function to report the caller site would obliviate >the need for all this ugliness Unfortunately the cost of this is prohabative as the call stack would have to contain backtrace information. Also due to lazy evaluation the 'call site' may not be what you expect. I guess we just have to disagree I find very little cause to use head. Here's what John Meacham had to say: ----------------------------------- Note that pattern matching rather than deconstruction functions have a number of benefits, not just relating to error messages, consider two functions which use the head of their argument. f xs =3D ... head xs ...=20 g (x:_) =3D ... x ... now, g is superior to f in several ways,=20 1) the error message generated if the pattern fails will have the file name, line number and name of function 2) everything but the head of xs may be garbage collected right away since there is no reference to the rest of the list! This can cure some nasty space leaks and is vital in certain cases.=20 3) even the simplest compiler will realize g is stirct in its first argument and take advantage of the numerous optimizations that entails.=20 A good compiler may figure out 2 and 3 with f, but it can't always, and w= hy take the chance it won't? All of these benefits apply to deconstructing more complicated types too, so using pattern matching for deconstruction is just a good habit to get into. -------------------------------------- Keean.

2 1

Re: [Haskell-cafe] exceptions vs. Either
by David Menendez 04 Aug '04

04 Aug '04

David Menendez writes: > MR K P SCHUPKE writes: > > > I would suggest using the type system as I said earlier so: > > > > toNonEmptyList :: [a] -> Maybe (NonEmpty a) > > toNonEmptyList (a0:_) = Just (NonEmpty a) > > toNonEmptyList _ = Nothing > > > > Then redefine head: > > > > head :: NonEmpty a -> a > > head (NonEmpty (a0:_)) = a0 > > Oleg described a similar technique a few months ago. > > From <http://haskell.org/pipermail/haskell/2004-June/014271.html>: > > |> newtype NonEmpty a = NonEmpty [a] -- the NonEmpty constructor should > |> -- be hidden (not exported from its module) > |> > |> head' (NonEmpty a) = head a -- no error can occur! Can use unsafe > version > |> tail' (NonEmpty a) = tail a -- no error can occur! Can use unsafe > version > |> > |> -- trusted function: the only one that can use NonEmpty constructor. > |> fork_list_len f g x = if null x then f else g (NonEmpty x) > |> > |> revers x = revers' x [] > |> where > |> revers' x accum = fork_list_len accum (g accum) x > |> g accum x = revers' (tail' x) ((head' x):accum) > > We have these equivalences: > > toNonEmptyList == fork_list_len Nothing Just > fork_list_len d f == maybe d f . toNonEmptyList > > I think defining 'toNonEmptyList' in terms of 'fork_list_len' is > cleaner, but that's just my personal taste. (As it happens, I ended up > defining a very similar function 'cons' in my recursion module[1]). > > [1] > <http://www.eyrie.org/~zednenem/2004/hsce/Control.Recursion.html#v% > 3Acons> -- David Menendez <zednenem(a)psualum.com> <http://www.eyrie.org/~zednenem/>

1 0

Re: [Haskell-cafe] exceptions vs. Either
by MR K P SCHUPKE 03 Aug '04

03 Aug '04

A lot of programming errors come from failure to correctly validate. I remember being taught to validate on input _and_ validate when you use a value. So I would say do both - use maybe for input functions, and exceptions for when you use a value. You can use the type system to make this more efficient. Imagine you want an integer between 10 and 20, you have a function like: newtype ValidInt = Valid Int validateInt :: Int -> Maybe ValidInt validateInt x | x>=10 && x<=20 = Just (Valid x) validateInt _ = Nothing Now when you validate on input - you produce an error if you get "Nothing" and in all the functions you use the value you use ValidInt instead of Int. This way you use the type system to differentiate between a valid int (does not need to be rechecked) and a normal int (which would need to be validated). Of course you must make sure you don't write more than one constructor function for ValidInt. This suggests a form of constrained constructor would be useful... Whilst this can be done in Haskell, it is not easy and involves reifying the value to a type, and using a type class to constrain the data statement. Really here we are dealing with dependant types, and this is much easier in a dependantly typed language like Epigram. Keean.

3 2

Re: [Haskell-cafe] exceptions vs. Either
by MR K P SCHUPKE 03 Aug '04

03 Aug '04

>> Is there any easy way (TH?) to amend these to output the line number Or use GHC's reifyLocation 'function' in a mapException. Keean.

1 0