[Haskell-cafe] static typing and interactivity

Simon Marlow simonmar at microsoft.com
Wed Sep 14 09:58:18 EDT 2005

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.


More information about the Haskell-Cafe mailing list