Impressions on GHC debugger

Pepe Iborra mnislaih at gmail.com
Thu Apr 19 11:10:05 EDT 2007


Thanks a lot for the feedback !

On 19/04/2007, at 15:59, Simon Marlow wrote:

> Thanks Alexey.  I'm working on ironing out all the wrinkles at the  
> moment.  Some of the things you point out, like the prompt, are  
> already on my ToDo list, and some others I didn't know about, but  
> I'll look into them all in due course.
>
> Cheers,
> 	Simon
>
> Alexey Rodriguez Yakushev wrote:
>> Yesterday I darcs-got the GHC HEAD to play with the debugger and I  
>> have the following impressions/bug/suggestions:
>> * I would like to know whether I am debugging mode (i.e. in a  
>> breakpoint) or not. For example
>>  > *Main>  -- normal prompt
>> and, for example,
>>  > *Main:[1] >  -- in breakpoint 1
>> now, if I evaluate expression "e" via "seq e ()" and it happens to  
>> trigger breakpoint 2, I would like to see something like
>>  > *Main:[1]:[2] >
>> or some better notation, but you get my point.
>> * The notation for printing a list is non-Haskell, consider the  
>> following evaluated head but unevaluated tail:
>>  > *Main> :print xs
>>  > xs = [True | (_t2::[Bool])]
>> I would have expected "True : (_t2::[Bool])"

I'm working mostly on :print now, while Simon and Bernie work on  
breakpoints.
As agreed in #haskell, the pretty printer will be haskellized  
promptly, and all Prolog traces will be eliminated :)

>> * Consider the following code:
>>  > mymap f [] = []
>>  > mymap f (x:xs) = f x:mymap f xs
>>  >
>>  > main = mapM_ putStrLn $ mymap ('a':) ["hello","bye"]
>> First, I set a breakpoint on line two. When I invoke "main", the  
>> breakpoint is triggered two times before "main" is done  
>> evaluating. Afterwards, If I type "main" at the ghci prompt again,  
>> the breakpoint is not triggered anymore! Even though ":show  
>> breaks" lists it.
>> * Again considering the code above, if I break at line 2:
>>  > Stopped at FreeVar2.hs:2:17-19
>>  > x :: GHC.Base.Unknown
>>  > f :: t -> a
>>  > xs :: [GHC.Base.Unknown]
>> Now I type "f" and the following message appears:
>>  > *** Exception: No match in record selector Var.tcTyVarDetails

In this case the debugger does cannot know what the type of t is.
We still need a good plan for functions. But I totally agree it  
shouldn't fail like that.

>> * I was wondering whether it would be nice to have a "break"  
>> function/primitive, so that you can write:
>>  > mymap f [] = []
>>  > mymap f (x:xs) = (break (f x):mymap f xs)
>> with "break" having type "a -> a" and inserting a breakpoint  
>> around the argument expression. It is handy to not have to  
>> recalculate lines. However I am not so sure anymore. Using line  
>> numbers is not as bad as I thought.
>> The debugger is a nice addition to GHC, and I look forward to the  
>> debugger being integrated into the Emacs Haskell mode!

Take a look at Shim[1]. The debugger integration will be there soon  
(well, sooner or later).

[1] http://shim.haskellco.de


Cheers
pepe



More information about the Glasgow-haskell-users mailing list