Debugging inside the typechecker knot

Ryan Scott ryan.gl.scott at gmail.com
Fri Aug 4 16:43:53 UTC 2017


> All the type-checking decisions are around the kinds of the types
floating through the system, so look there. You might want to know what
type that kind is classifying... perhaps print out the HsType before it's
lost.

In the problems I'm tackling, I don't care so much about the kind of the
TyCon I'm dealing with, but rather its type variables. Alas, I don't know
of a good way to inspect the changes that happen to these type variables
inside the knot--even printing out the *length* of tyConTyVars would result
in an infinite loop!

> Or, you could tackle #13737 and get rid of the knot altogether! :)

I didn't know about that ticket, thanks. I had noticed in some of the code
I frequently look at (TcGenGenerics, which generates Generic(1) instances)
that the generated code uses HsExpr for the generated instance methods, but
Type for the generated associated type family instances, which always felt
icky to me. Maybe I could start by trying to produce HsType in that
particular spot in the code (or does this need to be done all at once?).

Ryan S.

On Fri, Aug 4, 2017 at 7:33 AM, Richard Eisenberg <rae at cs.brynmawr.edu>
wrote:

> My secret is that I've been annoyed by this problem, too!
>
> Perhaps a better answer is that you probably don't need the information
> you don't have. All the type-checking decisions are around the kinds of the
> types floating through the system, so look there. You might want to know
> what type that kind is classifying... perhaps print out the HsType before
> it's lost.
>
> Or, you could tackle #13737 and get rid of the knot altogether! :)
>
> Richard
>
> On Aug 3, 2017, at 6:21 PM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:
>
> Recently, I've found myself wanting to make changes to code that works
> inside code where TyCons are knot-tied [1]. But I've found myself unable to
> make much progress, since my ability to debug this code is severely limited
> by the fact that I can't seem to trace anything. That is, if I try tracing
> anything that comes from a knot-tied TyCon, GHC will go into an infinite
> loop! This prevents me from learning *anything* about the types floating
> around in the code I want to fix, which is hugely annoying.
>
> How do others work around this problem? There must be *some* way to glean
> information about the types inside a typechecker knot, since others seem to
> be able to work within this space. How do you do it? And will you consider
> sharing your secrets?
>
> Ryan S.
> -----
> [1] See Note [Type-checking inside the knot] at
> http://git.haskell.org/ghc.git/blob/884bd21a917f607b5a44e038e06f78
> d0b765ea63:/compiler/typecheck/TcHsType.hs#l1087
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170804/fabbc403/attachment.html>


More information about the ghc-devs mailing list