RE: [Haskell-cafe] static typing and interactivity
On 18 August 2005 16:11, 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? I would really like to do this, and I've put some thought into how to do it. Basically you need 2 things: - A generic way to display data found in the heap. Heap data doesn't carry around it's type, but we need a way to display the arguments to polymorphic functions (for example). Fortunately GHCi has all the information about the layout of known data types, all that's needed is a way to map a heap closure to GHCi's representation of constructor (a DataCon), which is quite possible - some support from the dynamic linker is required, though. - A way to set breakpoints. This is far easier for interpreted code than for compiled code: for interpreted code we can just replace the appropriate BCO (byte code object) with a special breakpoint object. A breakpoint would contain information about its free variables, and a pointer to the original BCO. The harder part is to map source locations to byte code objects, retaining the information through the various compiler passes (HsDebug did some work in this direction, I believe). Anyone interested in working on this, please get in touch. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] static typing and interactivity
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
Re: [Haskell-cafe] static typing and interactivity
Hi Jake, program. How do most of the folks here debug their large code base? You might have some success with Hat, http://www.haskell.org/hat/, for debugging. Unfortunately unless you are doing Monadic computations, breakpoints don't really work as well as in strict imperative programs. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] static typing and interactivity
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] static typing and interactivity
On Thu, 2005-08-18 at 15:17 +0200, Ketil Malde wrote: Hi, 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 :-) You might be interested in Chameleon: http://www.comp.nus.edu.sg/~sulzmann/chameleon/ especially the type debugger. Bernie. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
