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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe