I look at the source code and think about it... Generally I code in vi,
then run ghci, or compile and run. I find from experience the type
errors are normally easy to fix, you just look at the error, and study
the structure of the function. If I still have problems I edit the code
to return or output intermediate values. From years of doing this I can
generally spot all my mistakes quickly... leaving only those situations
where I don't fully understand the algorithm as requiring serious
thought. Of course these are precisely those kind of problems for which
a debugger is not much good either.
Keean.
Jake Luck wrote:
>> One slight annoyance using Haskell is the inability to load modules
>> with type problems in the interactive environment (i.e. GHCi). When I
>> have a type error, it would be nice to have an interactive way to
>> explore what the compiler thinks about the types involved -- as it is,
>> I have to resort to adding type signatures more or less at random to
>> narrow down the problem.
>>>> I'm not sure if it is technically feasible to (partially) load a
>> module with definitions that fail type checking, but if it were, I
>> thing it would make developing Haskell programs even nicer :-)
>>> Along similiar lines, it would be quite nice if one can mark their
> haskell code(working or not) with "breakpoints" and drop the
> programmer into GHCi so they can poke around, especially inside a
> do-construct. e.g. something the evalutation engine can check during
> reduction maybe? I find myself writing a lot of testing frameworks,
> maybe this is a good thing!, when I program. How do most of the folks
> here debug their large code base?
>> jake
> _______________________________________________
> Haskell-Cafe mailing list
>Haskell-Cafe at haskell.org>http://www.haskell.org/mailman/listinfo/haskell-cafe