> 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@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@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?
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs