Inspecting function arguments in GHCi

Ben Gamari ben at
Tue Jan 26 15:28:20 UTC 2021

Andrew Kvapil <viluon at> writes:

> Hello,
> I'm interested in inspecting the strictness of functions at runtime
> and the depth of thunks "in the wild."

Hi Andrew,

Interesting. When I first read your introduction my first thought was to
rather walk the "normal" heap using ghc-heap or, perhaps, the relatively
new ghc-debug library [1] rather than introduce this feature in GHCi.
It's hard to know whether non-GHCi-based approach is viable without
knowing more about what you are doing, but it potentially brings the
benefit of generality: your analysis is not limited to programs with can
be run under GHCi.

Of course, it also brings some challenges: You would need to find a way
to associate info table symbols with whatever information you need of
from the Core program and in the presence of simplification tying your
results back to the source program may not be possible at all.


- Ben


> For this reason I'm modifying
> GHC 8.10.2, essentially to add additional information to breakpoints.
> I'd like to reuse the logic behind GHCi's :print command
> (pprintClosureCommand, obtainTermFromId, ...) for which I suppose I
> need Id's. Those however don't exist for destructuring patterns, such
> as those in the following equations:
>      last [x] = x
>      last (_:xs) = last xs
> So I'm wondering where would be a good place in the pipeline to
> transform patterns like these into at-patterns, to give them Id's.
> However, the breakpoint logic only looks at the free variables of the
> right-hand sides and not transitively, which means that e.g. in the
> following example neither ':print arg1' nor ':print as' works when the
> interpreter hits a breakpoint in the top level expression on the RHS:
>      qsort arg1@(a:as) = qsort left ++ [a] ++ qsort right
>        where (left, right) = (filter (<=a) as, filter (>a) as)
> Thus I'd also like to know how to extend the free var logic for
> Tickish that eventually leads to CgBreakInfo and :print's ability to
> inspect these bindings at runtime. My goal would be to determine to what
> extent was a thunk evaluated during function application.
Note that Luite's recent work on refactoring the bytecode generator to
produce code from STG is quite relevant here. In particular, you will
likely want to look at !4589 [1], which does the work of refactoring
Tickish to follow the Trees That Grow pattern. You would likely want to
do the same to capture your free variable information.


- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <>

More information about the ghc-devs mailing list