capabilities of GHC API

[Simon Marlow]

Lemmih wrote:
> On 5/19/07, Frederik Eaton <frederik at a5.repetae.net> wrote:
>> Hello,
>>
>> I think what I'm trying to do is too ambitious, but I thought I would
>> ask to see if it is possible. It seems like there is no easy way to do
>> it, given what I've seen of the GHC API.
>>
>> I would like to have a function, say it is called "this", which has
>> the following effect in ghci
>>
>> > let n = 2 in this
>> > n
>> 2
>>
>> In other words, it captures all the variables which are in scope, and
>> adds them to the GHCi environment. Somebody helpful will probably say
>> "But you can just write 'let n = 2'!", but that is not the aim. There
>> are several aims. One is to be able to look at the variables inside a
>> function which one is trying to debug, then inserting 'this' will
>> cause them to be in scope, I think that would be useful. A more
>> important aim is to be able to use existentially quantified variables
>> easily. Currently I can do:
>>
>> > reifyIntegral 5 (\n -> print $ reflectNum n)
>> 5
>>
>> but how can I get GHCi to have an 'n' binding which is inside the
>> function? Clearly just returning 'n' will not work:
>>
>> > reifyIntegral 5 id
>>
>> <interactive>:1:0:
>>     Inferred type is less polymorphic than expected
>> ...
>>
>> This is what I am thinking of doing, but as I said it seems ambitious.
>> There are several easier things one could think of:
>>
>> > let n = 2 in bind "n" n
>> > n
>> 2
>>
>> If it were possible to add bindings to the GHCi bindings list, then
>> this would be easy. Is it possible? The documentation doesn't seem to
>> mention such a capability.
>>
>> Also, probably another useful feature would be to combine 'this' with
>> something in the IO monad:
>>
>> > withProgName "blah" thisIO
>> > getProgName
>> "blah"
>>
>> So, are these things currently possible? Planned? Have the functions I
>> describe been implemented already? I think there is a GHCi debugger in
>> the works, so maybe functionality like this will be part of it, I
>> didn't want to start something on my own if that is the case...
> 
> This is pretty much that the GHCi debugger does expect it restores the
> environment at the end of a breakpoint.
> 
> If you have GHC-6.6 or greater, try: let n = 2 in GHC.Base.breakpoint ()

GHC.Base.breakpoint doesn't work in the HEAD at the moment.  We might want to 
restore it; I'm not sure.  Since breakpoints are almost everywhere, it didn't 
seem necessary.  I don't currently have breakpoints in either compiled code or 
expressions typed at the prompt, so you can't do exactly what Frederik was 
asking for, although if the code is in a source file then it works fine.

Instrumenting expressions typed at the prompt wouldn't be hard, I'll add that to 
the list.

The documentation for the GHCi debugger is here, FYI:

  http://www.haskell.org/ghc/dist/current/docs/users_guide/ghci-debugger.html

Cheers,
	Simon