Partial Loading and Debugging with GHCI
Hi all, I'm curious as to how one would go about debugging the following program: hello :: String hello = "Hello" world :: String world = "World" number :: Int number = 1 helloWorld :: String helloWorld = hello ++ " " ++ world -- This fails! bad :: String bad = hello ++ number Predictably once I load this program into ghci I get the following error: [1 of 1] Compiling Main ( TestCode.hs, interpreted ) TestCode.hs:14:15: Couldn't match expected type `[Char]' against inferred type `Int' In the second argument of `(++)', namely `number' In the expression: hello ++ number In the definition of `bad': bad = hello ++ number Failed, modules loaded: none. At this point what I want to do is to query the output type of the different functions like so:
:t hello but GHCI won't let me because the program hasn't been loaded.
I would then have to comment out 'bad', reload the program and query output types to my hearts content. This is fine for a small program, but when I have functions are downriver from 'bad', it gets extremely cumbersome. Is there a way to load a file such that functions that compile stay loaded in the interpreter even if something else fails? Thanks ... -deech
You can comment out the definition of bad and add a new one:
bad = undefined
The file should load properly. Functions that use "bad" will compile too,
but if they try to evaluate it an error will be raised.
(sorry, forgot to hit "reply to all" the first time)
On Thu, Apr 16, 2009 at 1:34 PM, aditya siram
Hi all, I'm curious as to how one would go about debugging the following program:
hello :: String hello = "Hello"
world :: String world = "World"
number :: Int number = 1
helloWorld :: String helloWorld = hello ++ " " ++ world
-- This fails! bad :: String bad = hello ++ number
Predictably once I load this program into ghci I get the following error: [1 of 1] Compiling Main ( TestCode.hs, interpreted )
TestCode.hs:14:15: Couldn't match expected type `[Char]' against inferred type `Int' In the second argument of `(++)', namely `number' In the expression: hello ++ number In the definition of `bad': bad = hello ++ number Failed, modules loaded: none.
At this point what I want to do is to query the output type of the different functions like so:
:t hello but GHCI won't let me because the program hasn't been loaded.
I would then have to comment out 'bad', reload the program and query output types to my hearts content. This is fine for a small program, but when I have functions are downriver from 'bad', it gets extremely cumbersome. Is there a way to load a file such that functions that compile stay loaded in the interpreter even if something else fails?
Thanks ... -deech
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
On Thu, 16 Apr 2009, aditya siram wrote:
I'm curious as to how one would go about debugging the following program:
Alternatively, instead of trying to find out what the type is (which might something completely unintelligible and unhelpful, due to Haskell's type inferencing), use :: liberally on subexpressions to say "I think the type here should be *blah*"; it will let you zoom in on the compiler-human mismatch much more quickly. I think this is one of the best ways of Haskell debugging. Cheers, Edward
On Thu, Apr 16, 2009 at 8:34 PM, Edward Z. Yang
On Thu, 16 Apr 2009, aditya siram wrote:
I'm curious as to how one would go about debugging the following program:
Alternatively, instead of trying to find out what the type is (which might something completely unintelligible and unhelpful, due to Haskell's type inferencing), use :: liberally on subexpressions to say "I think the type here should be *blah*"; it will let you zoom in on the compiler-human mismatch much more quickly. I think this is one of the best ways of Haskell debugging.
Cheers, Edward _______________________________________________
I use this technique a lot. By telling the compiler more and more about what you think out to be going on, you can ascertain much more quickly where you disagree with the compiler. Alex
participants (4)
-
aditya siram -
Alexander Dunlap -
Edward Z. Yang -
Sean Bartell