- ghc-devs - Haskell.org

Discussion: Static Safety via Distinct Interfaces for HsSyn ASTs
by Shayan Najd 25 Aug '17

25 Aug '17

In this thread, I am going to raise a topic for discussion. Please share your opinions and related experiences. Evaluation of type families within HsSyn ASTs, such as `PostTc`, with a fixed phase index, such as `GhcPs`, gives us distinct ASTs at the *compile-time*. However, when programming with these ASTs, we use patterns, such as `HsMultiIf :: PostTc p Type -> [LGRHS p (LHsExpr p)] -> HsExpr p` that are shared among phases. We can (1) introduce a layer of abstraction providing a set of type and pattern synonyms specific to each phase, such as `PsMultiIf :: [LPsGRHS LPsExpr] -> PsExpr`; and (2) updating code working on ASTs of specific phase to use the interface specific to the phase, such as by changing prefixes from `Hs` to `Ps` and by removing unused variables and placeholders; and (3) leaving untouched code working uniformly on ASTs of different phases (i.e., the generic functions in Trees that Grow terminology), such as the existing functions whose types are polymorphic on phase index. Some comments: - It can be done gradually and smoothly: we add three separate files in HsSyn (per each phase) containing the phase-specific interfaces, and gradually import them and do the changes per module. - Using the interfaces is optional: code using the current method (e.g., using `HsMultiIf`) should work just fine. - It introduces a layer of indirection and three more files to maintain. - It makes code working on HsSyn ASTs, such as the renamer, appear cleaner as placeholders and similar machinery are abstracted away by the interfaces (e.g., no need to import bits and pieces of `HsExtension`) - In theory, there should be zero impact on GHC's runtime performance. I am myself undecided about its benefit-cost ratio, but willing to at least implement the phase-specific interfaces. For me, abstracting away all the `PostRn` stuff, `Out` prefixed constructors, and dummy placeholders from the front-end code is the most valuable. Yours, Shayan

2 3

Stg-lint and bootstrapping (fails?)
by Gabor Greif 24 Aug '17

24 Aug '17

Hi all, I tried an stg-lint build thus: $ make V=1 GhcStage2HcOpts="-O1 -g -dstg-lint" ... and failed: "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -this-unit-id base-4.10.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/./autogen -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package-id rts -package-id ghc-prim-0.5.1.0 -package-id integer-gmp-1.0.1.0 -this-unit-id base -XHaskell2010 -O -dcore-lint -dno-debug-output -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -dynamic-too -c libraries/base/./System/Mem/Weak.hs -o libraries/base/dist-install/build/System/Mem/Weak.o -dyno libraries/base/dist-install/build/System/Mem/Weak.dyn_o "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -this-unit-id base-4.10.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/./autogen -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package-id rts -package-id ghc-prim-0.5.1.0 -package-id integer-gmp-1.0.1.0 -this-unit-id base -XHaskell2010 -O -dcore-lint -dno-debug-output -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -dynamic-too -c libraries/base/./Control/Monad/IO/Class.hs -o libraries/base/dist-install/build/Control/Monad/IO/Class.o -dyno libraries/base/dist-install/build/Control/Monad/IO/Class.dyn_o "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -this-unit-id ghc-8.3 -hide-all-packages -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -Icompiler/stage2/build -icompiler/stage2/build/./autogen -Icompiler/stage2/build/./autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP-DGHCI -optP-include -optPcompiler/stage2/build/./autogen/cabal_macros.h -package-id base-4.10.0.0 -package-id deepseq-1.4.3.0 -package-id directory-1.3.0.2 -package-id process-1.6.1.0 -package-id bytestring-0.10.8.2 -package-id binary-0.8.5.1 -package-id time-1.8.0.2 -package-id containers-0.5.10.2 -package-id array-0.5.2.0 -package-id filepath-1.4.1.2 -package-id template-haskell-2.12.0.0 -package-id hpc-0.6.0.3 -package-id transformers-0.5.2.0 -package-id ghc-boot-8.3 -package-id ghc-boot-th-8.3 -package-id ghci-8.3 -package-id unix-2.7.2.2 -package-id terminfo-0.4.1.0 -Wall -fno-warn-name-shadowing -this-unit-id ghc -XHaskell2010 -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing -O1 -g -dstg-lint -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -dynamic-too -c compiler/utils/Exception.hs -o compiler/stage2/build/Exception.o -dyno compiler/stage2/build/Exception.dyn_o /home/ggreif/%NoBackup%/ghc-head/libraries/base/dist-install/build/GHC/IO/Exception.hi Declaration for $fExceptionIOException4 Unfolding of $fExceptionIOException4: Failed to load interface for ?GHC.Fingerprint? There are files missing in the ?base-4.10.0.0? package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170815 for x86_64-unknown-linux): kindPrimRep * -> * typePrimRep (m_as6 :: * -> *) Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/simplStg/RepType.hs:344:5 in ghc:RepType kindPrimRep, called at compiler/simplStg/RepType.hs:305:18 in ghc:RepType typePrimRep, called at compiler/stgSyn/StgLint.hs:437:17 in ghc:StgLint Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <<ghc: 144952288 bytes, 38 GCs, 4093040/9445544 avg/max bytes residency (4 samples), 61M in use, 0.000 INIT (0.000 elapsed), 0.355 MUT (0.386 elapsed), 0.216 GC (0.216 elapsed) :ghc>> make[1]: *** [compiler/stage2/build/Exception.o] Error 1 make: *** [all] Error 2 What is the status of stg-lint? Is the above expected to happen? This is stock `master` branch as of today. Cheers, Gabor

3 10

Docs
by Simon Peyton Jones 22 Aug '17

22 Aug '17

Ben et al I’m getting this on Linux when making documentation. I have not modified any of this documentation. Any ideas? Simon reading sources... [ 97%] what_glasgow_exts_does reading sources... [100%] win32-dlls reading sources... [ 97%] what_glasgow_exts_does reading sources... [100%] win32-dlls /5playpen/simonpj/HEAD-1/docs/users_guide/editing-guide.rst:398: ERROR: Error in "ghci-cmd" directive: invalid option block. .. ghci-cmd:: :module; [*]⟨file⟩ :noindex: Load a module /5playpen/simonpj/HEAD-1/docs/users_guide/ghci.rst:496: ERROR: Error in "ghci-cmd" directive: invalid option block. .. ghci-cmd:: :{ :} Begin or end a multi-line GHCi command block. /5playpen/simonpj/HEAD-1/docs/users_guide/ghci.rst:527: ERROR: Error in "warning" directive: invalid option block. .. warning:: Temporary bindings introduced at the prompt only last until the next :ghci-cmd:`:load` or :ghci-cmd:`:reload` command, at which time they will be simply lost. However, they do survive a change of context with :ghci-cmd:`:module`: the temporary bindings just move to the new location. /5playpen/simonpj/HEAD-1/docs/users_guide/ghci.rst:533: ERROR: Error in "hint" directive: invalid option block.

2 2

Re: Alex install failure
by Ara Adkins 19 Aug '17

19 Aug '17

NFS can be pretty dodgy with transient files due to latency. Sometimes the delete takes appreciable time after the command is issued so the lock file might just be persisting. I’d try installing into a cabal sandbox on a local drive and see if the same issue crops up. _ara > On 18 Aug 2017, at 23:43, Simon Peyton Jones <simonpj(a)microsoft.com> wrote: > > | Hmm. Here's a shot in the dark: is home home directory mounted via NFS by > | any chance? > > Direct hit! (for the shot in the dark). Yes it's NFS mounted I think. So what? > > Simon > > | -----Original Message----- > | From: Ben Gamari [mailto:ben@smart-cactus.org] > | Sent: 18 August 2017 13:05 > | To: Simon Peyton Jones <simonpj(a)microsoft.com>; ghc-devs <ghc- > | devs(a)haskell.org> > | Subject: Re: Alex install failure > | > | Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org> writes: > | > | > Friends > | > I'm trying to update my installation of alex, on Unix (Ubuntu). But I > | > get the dump below It's complaining about a lock file being an invalid > | argument (see highlight below). > | > If I manually remove the file I get past that, it successfully > | > installs tf-random, but the same thing happens on the next package. So > | > I can install packages one at a time, but that's silly. > | > | Hmm. Here's a shot in the dark: is home home directory mounted via NFS by > | any chance? > | > | Cheers, > | > | - Ben > >

2 2

Re: Where to discuss the linear types extension of GHC?
by Boespflug, Mathieu 18 Aug '17

18 Aug '17

Hi Wolfgang, great to see interest in linear types! I would advise caution about building anything on top of the linear types extension at this time. If you have interesting use cases, however, do tell, so that these use cases can influence the design. This is pre-alpha software, meaning that it's not even good enough as a developer preview of all the basic features. It's an in-progress development branch, which is going to take time to stabilize. Furthermore, whether the feature makes it into GHC will depend on what the GHC proposals committee thinks about it. The current authors of the would-be extension have yet to draft a proposal and submit it to the committee. If we manage to write a proposal in time, based on a beta level implementation of linear types, and if the committee accepts the proposal, then maybe the feature can make it into GHC 8.4. Or in GHC 8.6. That's our hope, at any rate. But it could also be never, if the committee rejects the proposal... Best, -- Mathieu Boespflug Founder at http://tweag.io. On 18 August 2017 at 22:55, Wolfgang Jeltsch <wolfgang-it(a)jeltsch.info> wrote: > Hi! > > I just read through the README. According to it, there are several crucial > things not implemented yet (case and let come to my mind), and there are > some fundamental bugs (which make it very easy to circumvent linearity > checks, making the whole extension pointless). Is the situation still like > this? > > What are your honest expectations regarding the future development of the > linear types feature and its integration into the official GHC? Is it > realistic to hope for this feature to be available in a stable GHC version > withing, say, the next 12 months? I would like to use linearity in some > project of mine, but at the moment, I am unsure whether it is really a good > idea to rely on this feature becoming available. > > All the best, > Wolfgang > > Am Mittwoch, den 19.07.2017, 08:52 +0000 schrieb Edvard Hübinette: > > Hi Wolfgang, > > the updated README is live and can be found here > <https://github.com/tweag/ghc/tree/linear-types>! > > Cheers, > Edvard > > On Thu, 13 Jul 2017 at 17:54 Spiwack, Arnaud <arnaud.spiwack(a)tweag.io> > wrote: > > I think the answer to both questions can be the same: the github issue of > Tweag's ghc repo: https://github.com/tweag/ghc/issues . > > Regarding this particular bug: it is a known bug indeed. I'll be fixing it > soon. We're expanding the README to include known bugs and usage > instruction. > > Thanks a lot for your time and interest, > Arnaud > > On Thu, Jul 13, 2017 at 12:14 AM, Wolfgang Jeltsch < > wolfgang-it(a)jeltsch.info> wrote: > > Hi! > > Another question is where to submit bugs. I already found the first one 😉: > > GHCi> let dup :: a -> (a, a); dup x = (x, x) > > GHCi> let unsafeDup :: a ⊸ (a, a); unsafeDup = dup > > GHCi> :type unsafeDup > > unsafeDup :: a ⊸ (a, a) > > GHCi> unsafeDup True > > (True,True) > > > All the best, > Wolfgang > > Am Mittwoch, den 12.07.2017, 23:15 +0300 schrieb Wolfgang Jeltsch: > > Hi! > > I think I will have several questions about the linear types extension > when trying to use it in the near future. Furthermore, I also want to give > feedback on the design of this extension. What is the appropriate forum for > discussing the linear types extension? The GHC developers mailing list > might be an option. However, I think that it would be better to contact you > more directly regarding these matters. Is there some issue tracker or > discussion platform I should use? > > All the best, > Wolfgang > > > > >

2 1

RE: Alex install failure
by Simon Peyton Jones 18 Aug '17

18 Aug '17

That's what I did. It then succeeds in installing one package, and fails in the same way on the next one. So I can install packages one at a time, by deleting the lock file manually each time. Bizarre. Simon | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] | Sent: 18 August 2017 11:59 | To: Simon Peyton Jones <simonpj(a)microsoft.com> | Subject: Re: Alex install failure | | Try removing | | /home/simonpj/.ghc/x86_64-linux-8.2.1/package.conf.d/package.cache.lock | | | | On Fri, Aug 18, 2017 at 12:25 PM, Simon Peyton Jones via ghc-devs <ghc- | devs(a)haskell.org> wrote: | > Friends | > | > I’m trying to update my installation of alex, on Unix (Ubuntu). But I | > get the dump below | > | > It’s complaining about a lock file being an invalid argument (see | > highlight below). | > | > If I manually remove the file I get past that, it successfully | > installs tf-random, but the same thing happens on the next package. | > So I can install packages one at a time, but that’s silly. | > | > Any ideas? | > | > Simon | > | > | > | > cabal install alex | > | > Resolving dependencies... | > | > Configuring tf-random-0.5... | > | > Building tf-random-0.5... | > | > Failed to install tf-random-0.5 | > | > Build log ( /home/simonpj/.cabal/logs/tf-random-0.5.log ): | > | > cabal: Entering directory '/tcabal mp/cabal-tmp-26141/tf-random-0.5' | > | > Configuring tf-random-0.5... | > | > Building tf-random-0.5... | > | > Preprocessing library tf-random-0.5... | > | > [1 of 4] Compiling System.Random.TF.Gen ( src/System/Random/TF/Gen.hs, | > dist/build/System/Random/TF/Gen.o ) | > | > [2 of 4] Compiling System.Random.TF.Init ( | > src/System/Random/TF/Init.hs, dist/build/System/Random/TF/Init.o ) | > | > | > | > src/System/Random/TF/Init.hs:94:5: warning: [-Wdeprecations] | > | > In the use of ‘bitSize’ (imported from Data.Bits): | > | > Deprecated: "Use 'bitSizeMaybe' or 'finiteBitSize' instead" | > | > | | > | > 94 | | bitSize n > 64 = error "mkTFGen: case where size of Int > 64 | not | > implemented" | > | > | ^^^^^^^ | > | > [3 of 4] Compiling System.Random.TF ( src/System/Random/TF.hs, | > dist/build/System/Random/TF.o ) | > | > [4 of 4] Compiling System.Random.TF.Instances ( | > src/System/Random/TF/Instances.hs, | > dist/build/System/Random/TF/Instances.o ) | > | > Creating package registration file: | > | > /tmp/pkgConf-tf-random-05965166491189641421.5 | > | > Installing library in | > | > /home/simonpj/.cabal/lib/x86_64-linux-ghc-8.2.1/tf-random-0.5-ABDhxe3m | > XYlHUEE5hzgewx | > | > Registering tf-random-0.5... | > | > cabal: '/usr/local/bin/ghc-pkg' exited with an error: | > | > ghc-pkg: Couldn't open database | > | > /home/simonpj/.ghc/x86_64-linux-8.2.1/package.conf.d for modification: | > | > {handle: | > | > /home/simonpj/.ghc/x86_64-linux- | 8.2.1/package.conf.d/package.cache.lock}: | > | > hLock: invalid argument (Bad file descriptor) | > | > cabal: Leaving directory '/tmp/cabal-tmp-26141/tf-random-0.5' | > | > cabal: Error: some packages failed to install: | > | > QuickCheck-2.10.0.1 depends on tf-random-0.5 which failed to install. | > | > alex-3.2.1 depends on tf-random-0.5 which failed to install. | > | > tf-random-0.5 failed during the final install step. The exception was: | > | > ExitFailure 1 | > | > simonpj@cam-05-unx:~/code/HEAD$ | > | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs(a)haskell.org | > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h | > askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=02%7C01%7Csimonpj%40microsoft.com%7C3f6ad797e3454147fa5e08d4e62 | 821e2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636386507413664213&sda | ta=ex4vc7sfwhYQsoTNUKSrtdKZtIkDxDWor0CEKN0M4Wk%3D&reserved=0 | >

1 0

Failing Test Cases in HEAD
by Shayan Najd 14 Aug '17

14 Aug '17

In a freshly cloned GHC code base (c6462ab0...), in my system,`make test TEST="T13780c T13822"` fails. That is while `./validate` passes. I am rather new to GHC code base, and not so familiar with its build and testing system. So I was wondering whether this is an intended behaviour (e.g., some test cases are intentionally left out of `./validate`). Specifically, I follow the following steps: (1) `git clone --recursive git://git.haskell.org/ghc.git` (2) `cd ghc` (3) `cp mk/build.mk.sample mk/build.mk` (4) set `BuildFlavour = devel2` and then (5) ./boot (6) ./configure (7) make -j4 (8) make test TEST="T13780c T13822" I build in a variant of the docker image for GHC development on Linux (64 bit), if it matters. As it seems, Alan also gets the similar result on his system. I am investigating this, since my development of Growable ASTs is stalled due to some "GHC panic bug" when validating. (In my repo[1], I can successfully build with steps (2)-(7) above but `./validate` (and `make test TEST="T13780c T13822"`) fails) Thanks, Shayan [1] https://github.com/shayan-najd/GrowableGHC

2 1

How does GHC handle TcPluginContradiction?
by Nicolas Frisby 06 Aug '17

06 Aug '17

My TC plugin is identifying a contradiction, but that is not preventing the module from type checking, nor does GHC even raising a warning (with -Wall). This is not the behavior I was expecting. How confused am I? I've distilled the behavior that's confusing me down to the following example > module Test where > > class C a where f :: a -> () paired with a very silly plugin that always claims every constraint it sees is a contradiction. > module Contrarian (plugin) where > > import Plugins (Plugin(..),defaultPlugin) > import TcPluginM (tcPluginIO) > import TcRnTypes (TcPlugin(..),TcPluginResult(TcPluginContradiction)) > > plugin :: Plugin > plugin = defaultPlugin { tcPlugin = const (Just contrarianPlugin) } > > contrarianPlugin :: TcPlugin > contrarianPlugin = TcPlugin { > tcPluginInit = return () > , > tcPluginSolve = \() given derived wanted -> do > tcPluginIO $ putStrLn "Alternative facts!" > return $ TcPluginContradiction $ given ++ derived ++ wanted > , > tcPluginStop = \() -> return () > } Please review the following GHCi session. We start *without* the plugin. $ ghc --interactive Test.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Test ( Test.hs, interpreted ) Ok, 1 module loaded. *Test> f () <interactive>:1:1: error: * No instance for (C ()) arising from a use of `f' * In the expression: f () In an equation for `it': it = f () That behavior meets my expectations. Now let's add the plugin to see what contradictions cause to happen --- my naive guess is that we should see the same thing. (I don't really know what contradictions *should* cause GHC to do *differently* than the above.) The following is a continuation of the same session. *Test> :set -fplugin=Contrarian *Test> f () Alternative facts! Alternative facts! Alternative facts! Alternative facts! *** Exception: <interactive>:3:1: error: * No instance for (C ()) arising from a use of `f' * In the expression: f () In an equation for `it': it = f () (deferred type error) *Test> :t f Alternative facts! f :: a -> () Interesting: claiming the constraint is a contradiction seems to convert the type error to a deferred type error. Let's see if we can disable that (since it's not the behavior I want). *Test> :set -fno-defer-type-errors *Test> :t f Alternative facts! f :: a -> () *Test> f () Alternative facts! Alternative facts! Alternative facts! Alternative facts! *** Exception: <interactive>:3:1: error: * No instance for (C ()) arising from a use of `f' * In the expression: f () In an equation for `it': it = f () (deferred type error) <interactive>:7:1: error: * No instance for (Show (a0 -> ())) arising from a use of `print' (maybe you haven't applied a function to enough arguments?) * In a stmt of an interactive GHCi command: print it *Test> I seems we can't disable this behavior. That makes it seem pretty fundamental. So I'm guessing I'm confused about something, probably what TcContradiction achieves in terms of the user experience. The behavior I want is for my plugin to identify (relevant) contradictions and incur a static type error as soon as possible. I thought contradictions would achieve that, but I seem to be wrong. What I should be expecting regarding contradictions? How should I achieve my desired behavior? Perhaps I should try "solving" the contradiction constraints via an appeal to a TypeError constraint instead. Or maybe I should just leave the identified contradictions unsolved? Thanks. -Nick PS - A big thank you to Adam Gundry and Christiaan Baaij (and probably others) for the useful wiki pages, blog posts, and publications -- they've been a huge help for my learning about the typechecker via plugins! I'm very excited about this plugin, and I hope to share it soon, but I'd like to understand it better before I do.

2 3

Job opening: compiling to categories
by Conal Elliott 05 Aug '17

05 Aug '17

I have a job opening to work closely with me (at Target Digital) on the GHC plugin described in the paper *Compiling to Categories* <http://conal.net/papers/compiling-to-categories> as well as on applications, including machine learning. I’m especially looking for someone used to working inside of GHC and/or on GHC plugins. Mathematically oriented, solid background in programming language theory, denotationally inclined. Remote work is perfectly fine (and is what I do). – Conal

1 0

Debugging inside the typechecker knot
by Ryan Scott 04 Aug '17

04 Aug '17

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/884bd21a917f607b5a44e038e06f78d0b765ea6…

3 4