- Glasgow-haskell-users

Field accessor type inference woes
by Edward Kmett 05 Jul '13

05 Jul '13

It strikes me that there is a fairly major issue with the record proposal as it stands. Right now the class class Has (r :: *) (x :: Symbol) (t :: *) can be viewed as morally equivalent to having several classes class Foo a b where foo :: a -> b class Bar a b where bar :: a -> b for different fields foo, bar, etc. I'll proceed with those instead because it makes it easier to show the issue today. When we go to compose those field accessors, you very quickly run into a problem due to a lack of functional dependencies: When you go to define fooBar = foo.bar which is perfectly cromulent with existing record field accessors you get a big problem. fooBar :: (Foo b c, Bar a b) => a -> c The b that should occur in the signature isn't on the right hand side, and isn't being forced by any fundeps, so fooBar simply can't be written. Could not deduce (Foo b0 c) arising from a use of `foo' from the context (Bar a b, Foo b c) If you leave off the signature you'll get an ambiguity check error: Could not deduce (Foo b0 c) arising from the ambiguity check for `fooBar' from the context (Bar a b, Foo b c) bound by the inferred type for `fooBar': (Bar a b, Foo b c) => a -> c It strikes me that punting all functional dependencies in the record types to the use of equality constraints has proven insufficient to tackle this problem. You may be able to bandaid over it by including a functional dependency/type family class Has (r :: *) (x :: Symbol) where type Got r x :: * getFld :: r -> Got r x (or to avoid the need for type applications in the first place!) class Has (r :: *) (x :: Symbol) where type Got r x :: * getFld :: p x -> r -> Got r x This has some annoying consequences though. Type inference can still only flow one way through it, unlike the existing record accessors, and it would cost the ability to 'cheat' and still define 'Has' for universally quantified fields that we might have been able to do with the proposal as it stands. -Edward

6 12

Exposing newtype coercions to Haskell
by Joachim Breitner 04 Jul '13

04 Jul '13

Hi, this is related to http://hackage.haskell.org/trac/ghc/wiki/NewtypeWrappers#Proposal3. I tried to hack up a little prototype of this, and this “works” now: import GHC.NT newtype Age = Age Int deriving Show ageNT :: NT Age Int ageNT = createNT newtype MyList a = MyList [a] deriving Show myListNT :: NT (MyList a) [a] myListNT = createNT main = do let n = 1 :: Int let a = coerce (sym ageNT) 1 let l1 = [a] let l2 = coerce (listNT ageNT) l1 let l3 = coerce (sym myListNT) l2 print a print l2 print l3 will print Age 1 [1] MyList [1] and no unsafeCoerce and no map is used in the production of this output. The GHC.NT module provides: data NT a b coerce :: NT a b -> a -> b refl :: NT a a sym :: NT a b -> NT b a trans :: NT a b -> NT b c -> NT a c createNT :: NT a b listNT :: NT a b -> NT [a] [b] where createNT takes the place of the "deriving foo :: NT a b" syntax: At compile time, it is checked if its first type argument is a newtype of the second, and the corresponding coercion is inserted, otherwise an error is (well, will be) printed. The idea is that these coercions will be guaranteed to be free (or almost free; I am not sure if the coercion witness (NT a b) will actually be optimized away). The prototype can be found at https://github.com/nomeata/nt-coerce and is implemented as a GHC plugin compatible with GHC 7.6.3 (I chose this route as it means not having to compile GHC). You can check if it works for you via $ ghc -dcore-lint -package ghc --make test.hs && ./test The code itself is, well, at most prototype code quality and contains quite a number of hacks and other warts, mostly due to my inexperience with GHC hacking, and I could make use of some advice. Some more concrete questions: * How do I look up a module (here GHC.NT.Type) and a name therein (NT) in CoreM? I tried to go via getOrigNameCache, but passing the ModuleName name to lookupModuleEnv yielded Nothing, although it seems to me to be precisely the same name that I find in moduleEnvKeys. If I take the ModuleName from that list, it works. Similar problems with the OccEnv. Please see https://github.com/nomeata/nt-coerce/blob/edef9f4d4889dde651bb086e76c576f84… for what I tried (and how I worked around it). This work-around also prevents building the package with cabal right now. * I did not find generic Core traversal functions like traverse :: (Monad m) => (Expr a -> m (Maybe (Expr a))) -> Expr a -> m (Expr a) which I defined in https://github.com/nomeata/nt-coerce/blob/edef9f4d4889dde651bb086e76c576f84…. Are such traversals re-implemented everywhere or did I just not search well enough? * On the core level, once I have a TyCon, I also have all DataCons available. Is there already code present that checks if the currently compiled module really should see the data constructors, i.e. if they are exported? I see code in normaliseFfiType, but that seems to be integrated in the type checker, and it seems I need a GlobalRdrEnv; can I get such a thing in a Core2Core pass? Thanks, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

3 10

Re: PSA: GHC can now be built with Clang
by Austin Seipp 01 Jul '13

01 Jul '13

Thanks Manuel! I have an update on this work (I am also CC'ing glasgow-haskell-users, as I forgot last time.) The TL;DR is this: * HEAD will correctly work with Clang 3.4svn on both Linux, and OS X. * I have a small, 6-line patch to Clang to fix the build failure in primitive (Clang was too eager to stringify something.) Once this fix is integrated into Clang (hopefully very soon,) it will be possible to build GHC entirely including all stage2 libraries without any patches. The patch is here: http://llvm.org/bugs/show_bug.cgi?id=16371 - I am hoping this will also make it into XCode 5. * I still have to eliminate some warnings throughout the build, which will require fiddling and a bit of refactoring. The testsuite still probably won't run cleanly on Linux, at least, until this is done I'm afraid (but then again I haven't tried...) As for the infamous ticket #7602, the large performance regression on Mac OS X, I have some numbers finally between my fast-TLS and slow-TLS approach. ./gc_bench.slow-tls 19 500000 5 22 +RTS -H180m -N7 -RTS 395.57s user 173.18s system 138% cpu 6:50.71 total vs ./gc_bench.fast-tls 19 500000 5 22 +RTS -H180m -N7 -RTS 322.98s user 132.37s system 132% cpu 5:44.65 total Now, this probably looks totally awful from a scalability POV. And, well, yeah, it is. But I am almost 100% certain there is something extremely screwy going on with my machine here. I base this on the fact that during gc_bench, kernel_task was eating up about ~600% of my CPU consistently, giving user threads no time to run. I've noticed this with other applications that were totally unrelated too (close tweetbot -> 800% CPU usage,) so I guess it's time to learn DTrace. Or turn it on and off again or something. Ugh. Anyway, if you look at the user times, you get a nice 30% speedup which is about what we expect! On a related note, due to the source code structure at the moment, Linux/Clang hilariously suffers from this same bug. That's because while Clang on Linux supports extremely fast TLS via __thread (like GCC,) it falls back to pthread_getspecific/setspecific. I haven't fixed this yet. It'll happen after I fix #7602 and get it merged in. On my Linux machine, gc_bench also sees a consistent 30% speedup between these two approaches, so I think this is a relatively accurate measurement. Well, as accurate as I can be without running nofib just yet. So if you're just dying to have GHC HEAD built with Clang HEAD on Linux because you've got reasons, you should probably hold on. I also may have a similar, better approach to fixing #7602 that is not entirely as evil and sneaky as crashing the WebKit party. I'll follow up on this soon when I have more info in a separate thread to confer with Simon. With nofib results. I hope. But anyway, 7.8 will be shaping up quite nicely - in particular in the Mac OS X department, I hope. Please feel free to pester me with questions or if you attempt something and it doesn't work. On Tue, Jun 25, 2013 at 7:34 PM, Manuel M T Chakravarty <chak(a)cse.unsw.edu.au> wrote: > Austin, > > Thank you very much for taking care of all these clang issues — that is very helpful! > > Cheers, > Manuel > > Austin Seipp <aseipp(a)pobox.com>: >> Hi all, >> >> As of commit 5dc74f it should now be possible to build a working >> stage1 and stage2 compiler with (an extremely recent) Clang. With some >> caveats. >> >> You can just do: >> >> $ CC=/path/to/clang ./configure --with-gcc=/path/to/clang >> $ make >> >> I have done this work on Linux. I don't expect much difficulty on Mac >> OS X, but it needs testing. Ditto with Windows, although Clang/mingw >> is considered experimental. >> >> The current caveats are: >> >> * The testsuite will probably fail everywhere, because of some >> warnings that happen during the linking phase when you invoke the >> built compiler. So the testsuite runner will probably be unhappy. >> Clang is very noisy about unused options, unlike GCC. That needs to be >> fixed somewhere in DriverPipeline I'd guess, but with some >> refactoring. >> * Some of the stage2 libraries don't build due to a Clang bug. These >> are vector/primitive/dph so far. >> * There is no buildbot or anything to cover it. >> >> You will need a very recent Clang. Due to this bug (preventing >> primitive etc from building,) you'll preferably want to use an SVN >> checkout from about 6 hours ago at latest: >> >> http://llvm.org/bugs/show_bug.cgi?id=16363 >> >> Hilariously, this bug was tripped on primitive's Data.Primitive.Types >> module due to some CPP weirdness. But even with a proper bugfix and no >> segfault, it still fails to correctly parse this same module with the >> same CPP declarations. I'm fairly certain this is another bug in >> Clang, but I might be wrong. I'm trying to isolate it. Unfortunately >> Clang/LLVM 3.3 was just released and it won't see bugfix releases. But >> it will *probably* work if we just get rid of the CPP tomfoolery in >> primitive. I'll be testing it in the next few days to see if we can >> get 3.3 supported. (I'm sort of kicking myself in the head for not >> doing this a week or two ago...) >> >> Anyway, there are some rough edges but it should be in shape for 7.8 I >> hope. It should be especially welcome for Mac users. (I'm also hoping >> modern Macs could even go all-clang-all-the-time if my fix for #7602 >> can go in soon...) >> >> PS. If you use ASSERT, I just fixed a lot of instances of using that >> macro, involving whitespace between the name and arguments (commit >> d8ee2b.) Clang does not forgive you for this. Should I note this >> anywhere for the future in the wiki or something? >> >> -- >> Regards, >> Austin - PGP: 4096R/0x91384671 >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin - PGP: 4096R/0x91384671

5 6

Who uses Travis CI and can help write a cookbook for those guys?
by Ryan Newton 28 Jun '13

28 Jun '13

The Travis folks have decided they want to support Haskell better (multiple compiler versions): https://github.com/travis-ci/travis-ci/issues/882#issuecomment-20165378 (Yay!) They're asking for someone to help them up with setup scripts. They mention their cookbook collection here: https://github.com/travis-ci/travis-cookbooks In that thread above, I pasted our little script that fetches and installs multiple GHC versions, but I have little experiences with cloud technologies & VMs. Can someone jump in and help push this forward? As a community I'm sure it would be great to get a higher percentage of Hackage packages using simple, hosted continuous testing... I'd personally like to replace my Jenkins install if they can get the necessary GHC versions in there. Best, -Ryan

1 0

Repeated variables in type family instances
by Richard Eisenberg 26 Jun '13

26 Jun '13

(Sorry for the re-send - got the wrong subject line last time.) Hello all, It's come to my attention that there is a tiny lurking potential hole in GHC's type safety around type families in the presence of UndecidableInstances. Consider the following: > type family F a b > type instance F x x = Int > type instance F [x] x = Bool > > type family G > type family G = [G] This declarations are all valid in GHC 7.6.3. However, depending on the reduction strategy used, it is possible to reduce `F G G` to either Int or Bool. I haven't been able to get this problem to cause a seg-fault in practice, but I think that's more due to type families' strictness than anything more fundamental. Thus, we need to do something about it. I have written a proposal on the GHC wiki at http://hackage.haskell.org/trac/ghc/wiki/NewAxioms/Nonlinearity It proposes a change to the syntax for branched instances (a new form of type family instance that allows for ordered matching), but as those haven't yet been officially released (only available in HEAD), I'm not too worried about it. There are two changes, though, that break code that compiles in released versions of GHC: --- 1) Type family instances like the two for F, above, would no longer be accepted. In particular, the overlap check for unbranched (regular standalone instances like we've had for years) would now check for overlap if all variables were distinct. (This freshening of variables is called 'linearization'.) Thus, the check for F would look at `F x y` and `F [x] y`, which clearly overlap and would be conflicting. 2) Coincident overlap between unbranched instances would now be prohibited. In the new version of GHC, these uses of coincident overlap would have to be grouped in a branched instance. This would mean that all equations that participate in coincident overlap would have be defined in the same module. Cross-module uses of coincident overlap may be hard to refactor. --- Breaking change #1 is quite necessary, as that's the part that closes the hole in the type system. Breaking change #2 is strongly encouraged by the fix to #1, as the right-hand side of an instance is ill-defined after the left-hand side is linearized. It is conceivable that there is some way to recover coincident overlap on unbranched instances, but it's not obvious at the moment. Note that this proposal does not contain a migration path surrounding coincident overlap. In GHC <= 7.6.x, branched instances don't exist and we have coincident overlap among unbranched instances; and in GHC >= 7.8.x, we will prohibit coincident overlap except within branched instances. We (Simon PJ and I) think that this shouldn't be too big of a problem, but please do shout if it would affect you. Please let me know what you think about this proposal! Thanks, Richard

3 10

Type families causing the compiler to hang on recompilation
by Jeroen Weijers 21 Jun '13

21 Jun '13

Hello, I am having a problem with (re)compiling some code I have. I have two modules A and B. In A I have some classes and instances and B uses this. When I try to compile B (with cabal or ghc --make) the first time everything works. When I now modify B (add a space) B is recompiled but the compiler hangs and doesn't seems to be doing anything. I have tested the problem with GHC (x86_64) 7.6.2. 7.6.3 and HEAD. It seems to be very similar to a problem I had earlier: http://hackage.haskell.org/trac/ghc/ticket/7321 but this time there are no GADTs involved. The code of module A (clutter that doesn't contribute to the problem has been removed): > {-# LANGUAGE FlexibleInstances, UndecidableInstances #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE TypeFamilies, TypeOperators, ScopedTypeVariables #-} > {-# LANGUAGE FlexibleContexts #-} > {-# LANGUAGE DataKinds, PolyKinds #-} > > module A where > > import GHC.Generics > > class QA a where > type QRep a > type QRep a = QRep (GRep (Rep a)) > > instance QA () where > type QRep () = () > > -- Kind-polymorphic proxies; > data Pr (a :: k) = Pr > > class (QA (GRep f)) => CaseOf (f :: * -> *) where > type Alg f r k :: * > type GRep f :: * > > -- Only used for the product structure > class QA (ProdRep f) => CaseOfProd (f :: * -> *) where > type ProdAlg f r :: * > type ProdRep f :: * The code of module B: > module B where > import qualified A Given that the code type checks (and if I do not recompile and make an executable directly it actually works) I think this is a bug that might be similar to the bug mentioned in ticket 7321. Does anybody recognise the problem? Should I create a ticket? Cheers, Jeroen Weijers

2 2

GADTs and pattern matching
by Francesco Mazzoli 19 Jun '13

19 Jun '13

Hi list, I had asked this on haskell-cafe but this looks particularly fishy, so posting here in case it is an issue: {-# LANGUAGE GADTs #-} data Foo v where Foo :: forall v. Foo (Maybe v) -- Works foo1 :: Foo a -> a -> Int foo1 Foo Nothing = undefined foo1 Foo (Just x) = undefined -- This works foo2 :: a -> Foo a -> Int foo2 x Foo = foo2' x foo2' :: Maybe a -> Int foo2' Nothing = undefined foo2' (Just x) = undefined -- This doesn't! foo3 :: a -> Foo a -> Int foo3 Nothing Foo = undefined foo3 (Just x) Foo = undefined So it looks like constraints in pattern matching only propagate forwards. Is this intended? Thanks, Francesco

1 1

ConstraintKinds feature suggestion and question about type family peculiarity
by Merijn Verstraaten 17 Jun '13

17 Jun '13

Hello fellow haskellers! I was experimenting with restricting functions operating on GADTs with phantom types to only work on a subset of the possible phantom types. I ended up with the following code: {-# LANGUAGE ConstraintKinds, DataKinds, GADTs, TypeFamilies, TypeOperators #-} import GHC.Prim (Constraint) data Foo a where Foo :: Foo Int Bar :: Foo Char Baz :: Foo Bool type family Restrict a (as :: [*]) :: Constraint type instance where Restrict a (a ': as) = () Restrict x (a ': as) = Restrict x as foo :: Restrict a '[Char, Bool] => Foo a -> Bool foo Bar = True foo Baz = False This seems to works marvellously, but in writing it I ran into 2 annoyances. 1) The type errors produced by trying to use a function on a disallowed phantom type are rather unclear. "Could not deduce (Restrict Int ('[] *)) arising from a use of ‛foo" Which got me thinking, it would be really nice to have a vacuous Constraint that takes an error string as argument, i.e. a constraint that never holds and returns it's error string as type error. This would let you produce far nicer type errors when (ab)using ConstraintKinds and TypeFamilies by, for example, adding an extra Restrict instance "Restrict x '[] = Vacuous "Applying restricted function to disallowed type"" (or something to that effect), producing that message as error rather than the "Could not deduce (Restrict Int ('[] *)" which is a rather unhelpful error if you're not the person that wrote this code and are just using a function with such a Restrict constraint. 2) for some reason the type families syntax always requires a full argument list, which I find rather ugly. I would much prefer to use KindSignatures and write "type family Restrict :: * -> [*] -> Constraint", but GHC does not allow this. Is there a specific reason for not allowing this syntax? Cheers, Merijn Verstraaten

3 2

Cross-compiling GHC: ghc-cabal: /tmp/30869.o: does not exist
by Nikita Karetnikov 14 Jun '13

14 Jun '13

I'm trying to cross-compile GHC 7.6.3; 'make' fails with the mentioned error. How can I debug this issue? I used Guix [1] to build a cross-compiler and related packages: # ./pre-inst-env guix build -K gcc-cross-mips64el-linux-gnu After that I downloaded GHC 7.6.3: # wget http://www.haskell.org/ghc/dist/7.6.3/ghc-7.6.3-src.tar.bz2 Unpacked it: # tar xf ghc-7.6.3-src.tar.bz2 # cd ghc-7.6.3/mk # cp build.mk.sample build.mk Uncommented 'BuildFlavour = unreg' and added 'INTEGER_LIBRARY = integer-simple'. # cd .. # export CROSS_LIBRARY_PATH=/nix/store/qkzhg178l4b3fpnj7ival0h6c1mfgi0l-glibc-cross-mips64el-linux-gnu-2.17/lib # export CROSS_CPATH=/nix/store/qkzhg178l4b3fpnj7ival0h6c1mfgi0l-glibc-cross-mips64el-linux-gnu-2.17/include:/nix/store/g4ky5zb70y946pfjiq45sa5pv7qdqgha-linux-libre-headers-cross-mips64el-linux-gnu-3.3.8/include # ./configure \ --target=mips64el-linux-gnu \ --with-gcc=/nix/store/lv3vxm43mmk7f5gc1myzs0aj8pi4a4g7-gcc-cross-mips64el-linux-gnu-4.7.3/bin/mips64el-linux-gnu-gcc \ --with-ld=/nix/store/jys3nw5rg2a4lrihs7qhflxad4bwyry6-binutils-cross-mips64el-linux-gnu-2.23.2/bin/mips64el-linux-gnu-ld \ --with-nm=/nix/store/jys3nw5rg2a4lrihs7qhflxad4bwyry6-binutils-cross-mips64el-linux-gnu-2.23.2/bin/mips64el-linux-gnu-nm # make [...] CROSS_COMPILE="mips64el-unknown-linux-gnu-" "inplace/bin/ghc-cabal" configure --with-ghc="/home/GHC/ghc-7.6.3/inplace/bin/ghc-stage1" --with-ghc-pkg="/home/GHC/ghc-7.6.3/inplace/bin/ghc-pkg" --flag=include-ghc-prim --disable-library-for-ghci --configure-option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" -Wl,--hash-size=31 -Wl,--reduce-memory-overheads " --configure-option=CPPFLAGS=" " --with-gcc="/nix/store/lv3vxm43mmk7f5gc1myzs0aj8pi4a4g7-gcc-cross-mips64el-linux-gnu-4.7.3/bin/mips64el-linux-gnu-gcc" --configure-option=--with-cc="/nix/store/lv3vxm43mmk7f5gc1myzs0aj8pi4a4g7-gcc-cross-mips64el-linux-gnu-4.7.3/bin/mips64el-linux-gnu-gcc" --with-ar="/usr/bin/ar" --with-ranlib="true" --with-alex="/usr/bin/alex" --with-happy="/usr/bin/happy" -- dist-install libraries/ghc-prim Configuring ghc-prim-0.3.0.0... ghc-cabal: /tmp/30869.o: does not exist make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error 1 make: *** [all] Error 2 Then I found this bug report [2] and decided to apply the mentioned patch: # cd .. # git clone https://github.com/ghc/ghc.git ghc-github # cd ghc-github # git show f77291d60f33fe601dbe0ff94b0192c5cd4ad6b5 > ld.patch # cd ../ghc-7.6.3 # patch -p1 < ../ghc-github/ld.patch patching file rules/build-package-data.mk Hunk #1 succeeded at 64 (offset -11 lines). # make distclean # ./configure [...] # make Then another error appeared: CROSS_COMPILE="" "inplace/bin/ghc-cabal" configure --with-ghc="/usr/local/bin/ghc" --with-ghc-pkg="/usr/local/bin/ghc-pkg" --package-db=/home/GHC/ghc-7.6.3/libraries/bootstrapping.conf --disable-library-for-ghci --configure-option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" -Wl,--hash-size=31 -Wl,--reduce-memory-overheads " --configure-option=CPPFLAGS=" " --constraint "Cabal == 1.16.0" --constraint "hpc == 0.6.0.0" --constraint "binary == 0.5.1.1" --constraint "bin-package-db == 0.0.0.0" --constraint "hoopl == 3.9.0.0" --with-gcc="/usr/bin/gcc" --with-ld="/nix/store/jys3nw5rg2a4lrihs7qhflxad4bwyry6-binutils-cross-mips64el-linux-gnu-2.23.2/bin/mips64el-linux-gnu-ld" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" --with-ranlib="true" --with-alex="/usr/bin/alex" --with-happy="/usr/bin/happy" -- dist-boot libraries/Cabal/Cabal Configuring Cabal-1.16.0... ghc-cabal: /tmp/27862.o: does not exist make[1]: *** [libraries/Cabal/Cabal/dist-boot/package-data.mk] Error 1 make: *** [all] Error 2 I can't find any similar reports. Am I on the right track? [1] https://gnu.org/software/guix/ [2] http://hackage.haskell.org/trac/ghc/ticket/6086

1 0

Re-entrant TcRnIf
by p.k.f.holzenspies＠utwente.nl 13 Jun '13

13 Jun '13

Dear GHC-ers, The current API *seems* to assume that all different stages of the compiler pipeline are always passed successively (with the exception of the interleaving of the renamer and the type checker for the sake of Template Haskell), in other words, it is assumed all parsing has been done once we start renaming and that when we desugar the AST, we can through out all type checker state. I'm working on an interactive environment (different in many ways from ghci), in which I would like to incrementally parse a statement, rename it and type check it, after which I may chose to wash, rinse and repeat. This is somewhat problematic in the renamer (at least; this is how far I have come), at the very least with regards to the unique source and the provenance of things. What I'm hoping to do is to generalize the monads in the GHC API to some class, along these lines: class Generalizes m n where glift :: n a -> m a class (GhcMonad m, Generalizes m TcRnIf, Generalizes m CoreM, ...) => GHCAPI m What such a monad needs is to be able to evaluate some function in (for example) the renamer monad, extract the part of the renamer state that needs to persist and store that for whenever another renamer function is evaluated. One such thing would be the supply of unique names. I tried simply carrying over everything in the Env, except the env_top (HscEnv), but this broke things. Upon inspection of the TcGblEnv and TcLclEnv, this seems logical, considering they are dependent on the HscEnv (at least in terms of tcg_type_env_var, but there may be other dependencies I've not spotted). The thing that seems to bite me is the assumption that the top-level environment is assumed to be fixed [1]. In my scenario, this assumption does not hold. Concretely: 1) Do ways exist to carry over the part of the TcRnMonad state that is required to restart the renamer / type checker / etc later on? 2) If not, what parts of the Env, TcGblEnv and TcLclEnv should I copy over to the new state, assuming the HscEnv changed between consecutive runs? 3) Is there a particular reason why the front-end (of the front-end) is defined in an overloaded monad (GhcMonad) and the later bits all take concrete monads (TcRnIf etc.)? Regards, Philip [1] http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/TcRnMonad

2 2