- Haskell - Haskell.org

RE: [Haskell] modern language design, stone age tools
by Simon Marlow 24 Jun '04

24 Jun '04

On 24 June 2004 11:54, MR K P SCHUPKE wrote: > With reference to "mapException", I thought this seemed a good idea. > I like the 'AnnotatedException' idea... this is much better than > concatenating strings... However for not I thought I would test it > as is, but it doesn't work as I thought - perhaps someone could > point out where I have gone wrong. > > 1) this works: > > main :: IO () > main = do > a <- getLine > hPutStrLn $ showInt (fst . head . readDec $ a :: Int) > `Exception.catch` (\e -> throw $ ErrorCall $ showString "Urk :" $ > show e) > > 2) this doesn't work: > > main :: IO () > main = mapException (\x -> ErrorCall $ showString "Urk :" $ show x) $ > do a <- getLine > hPutStrLn $ showInt (fst . head . readDec $ a :: Int) This is due to the nature of exceptions in Haskell. Evaluating the expression (do a <- getLine; hPutStrLn ...) does not do any IO, and it doesn't raise any exceptions, so the mapException doesn't get to annotate any exceptions. What you really wanted here was (untested) mapExceptionIO :: IO a -> (Exception -> Exception) -> IO a mapExceptionIO io f = catch io (\e -> throwIO (f e)) probably we should have this in Control.Exception too. Cheers, Simon

2 1

Re: [Haskell] modern language design, stone age tools
by MR K P SCHUPKE 24 Jun '04

24 Jun '04

With reference to "mapException", I thought this seemed a good idea. I like the 'AnnotatedException' idea... this is much better than concatenating strings... However for not I thought I would test it as is, but it doesn't work as I thought - perhaps someone could point out where I have gone wrong. 1) this works: main :: IO () main = do a <- getLine hPutStrLn $ showInt (fst . head . readDec $ a :: Int) `Exception.catch` (\e -> throw $ ErrorCall $ showString "Urk :" $ show e) 2) this doesn't work: main :: IO () main = mapException (\x -> ErrorCall $ showString "Urk :" $ show x) $ do a <- getLine hPutStrLn $ showInt (fst . head . readDec $ a :: Int) Keean. (using GHC-6.2)

1 0

RE: [Haskell] modern language design, stone age tools
by Simon Marlow 24 Jun '04

24 Jun '04

On 24 June 2004 10:31, Alastair Reid wrote: >> [...] >> 2. Use the mapException trick to annotate exceptions as they >> travel up the stack (see Alastair Reid's message). [...] >> (2) requires that you add lots of annotations to your code, so it's >> not entirely satisfactory for that reason. > > Would it be possible to generalise ghc's -prof-all mechanism so that > annotations could be added automatically. For example, suppose I have > an annotation function > > Debug.Callstack.callstack :: ModuleName -> LineNumber -> a -> a > > Then, if I compile with: > > ghc -annotate=Debug.Callstack.callstack Foo.hs > > then ghc could add > > import Debug.Callstack(callstack) > > to the import list and transform every top level function body > as follows: > > foo (x:xs) = .. > foo [] = ... > => > foo arg = callstack > "Foo" -- module name > 42 -- line number > (foo' arg) > foo' (x:xs) = .. > foo' [] = .. Yes, this could be done. I should have mentioned though: this technique gives you the lazy call stack, whereas what you probably want is the strict call stack (which is what GHC's profiler tries to give you). Getting the lazy call stack is easy from a debugger, we don't need to annotate the program to do that, but we might want to add source locations in the form of debug info to the object file in a similar way to C compilers. It may be that giving programmers access to the lazy call stack is a heck of a lot better than nothing. Cheers, Simon

1 0

RE: [Haskell] modern language design, stone age tools
by Simon Marlow 24 Jun '04

24 Jun '04

On 23 June 2004 18:39, Fergus Henderson wrote: > On 23-Jun-2004, MR K P SCHUPKE <k.schupke(a)imperial.ac.uk> wrote: >> This may not be the right answer to the question (which is of >> course lets write a debugger) - But I have never used a debugger, >> and find them more or less the most unfriendly and useless things > > So how do you debug problems like "Prelude.head: empty list" > in large programs? The two most useful techniques, both have which have already been suggested by others are: 1. Compile with -prof -auto-all and run with +RTS -xc. 2. Use the mapException trick to annotate exceptions as they travel up the stack (see Alastair Reid's message). (1) doesn't work that well, as you noticed. For example, sometimes the exception will stop at a CAF, due to the way cost centres work in GHC. I'd really like us to do better here - keeping track of the call stack in a lazy higher-order language has turned out to be surprisingly tricky. (2) requires that you add lots of annotations to your code, so it's not entirely satisfactory for that reason. Even if we had an interactive debugger, getting a good call stack is still going to be a hard problem. Cheers, Simon

2 1

Re: [Haskell] modern language design, stone age tools
by MR K P SCHUPKE 24 Jun '04

24 Jun '04

>Thank you for the programming practice recomendation, Sorry if it seemed like that... I was really trying to suggest practical measures that someone could use in the absence of a debugger - but I do feel that 'commercial quality' code should be bullet proof, and of a different calibre to code for personal use, or academic research. Keean.

2 1

Re: [Haskell] modern language design, stone age tools
by MR K P SCHUPKE 23 Jun '04

23 Jun '04

>So how do you debug problems like "Prelude.head: empty list" >in large programs? I normally dont use head, but instead code: case x of (a0:_) -> <expr1> _ -> fail <debug info> for precisely this reason - and the fact that I dont like bindings that can fail... Keean.

2 1

Re: [Haskell] modern language design, stone age tools
by Fergus Henderson 23 Jun '04

23 Jun '04

On 23-Jun-2004, Hal Daume III <hdaume(a)ISI.EDU> wrote: > On Wed, 23 Jun 2004, Fergus Henderson wrote: > > > On 23-Jun-2004, MR K P SCHUPKE <k.schupke(a)imperial.ac.uk> wrote: > > > This may not be the right answer to the question (which is of > > > course lets write a debugger) - But I have never used a debugger, > > > and find them more or less the most unfriendly and useless things > > > > So how do you debug problems like "Prelude.head: empty list" > > in large programs? > > Wasn't addressed to me, but here's what I do: > > write the following function: > > head_ x [] = error ("head_: " ++ show x) > head_ _ l = head l > > and then replace each occurance of "head" with "head_ 1" or "head_ 2" > etc., so I can know where it failed. Well, there are quite a lot of such occurrences in the code that I'm working on: bash$ find . -name \*.hs -o -name \*.lhs | xargs grep -w head | wc -l 130 Replacing all of those occurrences by hand is going to be very very tedious and somewhat time-consuming. Doing it with a script would be better, but that's not a trivial task. Even once that is done, there's no guarantee it will actually help to find the problem. After all, the problem might well be arising from a call to "head" in one of ghc's standard libraries: bash$ find ~/ghc6-6.2/hslibs \*.hs -o -name \*.lhs | xargs grep -w head | wc -l 104 So not only do I have to edit my own code, and the libraries written by my colleagues, I also need to edit the ghc library code, and figure out how to build and reinstall the ghc libraries. That could take a long time. After all that, hopefully I will finally know which function called "head" with an empty list. But even then there's still no guarantee that I've actually found the source of the problem; the real problem might be in that function's caller, or the caller's caller, etc. So I might have to go through the whole process again. > (it is rather sad that this is the best approach i could come up > with...basically tries to get around the [lack of/uselessness of/inability > to use with ghci] stack traces) Yes :-( -- Fergus J. Henderson | "I have always known that the pursuit Galois Connections, Inc. | of excellence is a lethal habit" Phone: +1 503 626 6616 | -- the last words of T. S. Garp.

4 3

RE: [Haskell] modern language design, stone age tools
by MR K P SCHUPKE 23 Jun '04

23 Jun '04

This may not be the right answer to the question (which is of course lets write a debugger) - But I have never used a debugger, and find them more or less the most unfriendly and useless things You either end up single stepping through a million lines of code, or you find the error is of a complex non-localised kind anyway. I find inserting my own debug code into an application to be a much more fruitful way of keeping track of errors. Using conditional compiliation all this extra code can be removed from a finished app. The only problem with this approach in Haskell is that you sometimes have to lift a function into the IO monad for debugging... Keean.

4 3

Re: [Haskell] modern language design, stone age tools
by MR K P SCHUPKE 23 Jun '04

23 Jun '04

I like to write programs so functions cannot fail... so head should really be: maybeHead :: [a] -> Maybe a maybeHead (a:_) = Just a maybeHead _ = Nothing etc... The the calling function can do something like: case maybeHead x of Just y -> <expr y> Nothing -> fail "failed in..." This way you can pass the failure back up to somewhere where its meaningful. In my opinion you should either be encoding failure in the return type, or using exceptions... anything else is just bad coding. Finally use guards (that can be conditionally compiled out) before functions that might fail: if null x then fail "sesible error message" else ... Keean.

2 1

Re: [Haskell] modern language design, stone age tools
by MR K P SCHUPKE 23 Jun '04

23 Jun '04

>Hmmm... chickens and eggs. I don't see a lot of *companies* using Haskell Actually I have used Haskell in commercial projects... and am continuing to do so. My development environment is Vim and GHC. Same one I have used for C/C++ VHDL Perl, and anything else... It is not that lack of GUI tools, but just the lack of coders that is the problem (or the price)... With my consultants hat on, looking at starting a project we ask how much is it going to cost to get a coder fluent in this language and how easily can one be found at short notice. I just think the intellectual barriers to becomming a Haskell coder are a bit higher (understanding monads etc) - meaning less people can do it. I know plenty of real world developers using other languages that also do not use debuggers very much if at all. The only fix I can see it when the world wakes up to the fact that side effects and weak typing lead to buggy programs, and realise that is unacceptable. Unfortunately in business a buggy program is often good enough. Basically if it is delivered on time is can be full of bugs - but the customer won;t notice them all right away - so you can get paid, and just fix those the customer finds really annoying. This can be cheaper than trying to produce 100% correct code. Keean.

1 0