Re: Adding a module

Simon Peyton Jones via ghc-devs writes: > If you add a module to GHC, I know you need to extend ghc.cabal.in. But > also ghc.mk? Otherwise I get hits > > > If you add a module to GHC, I know you need to extend ghc.cabal.in. But > also ghc.mk? Otherwise I get hits >

Re: Adding a module

That's correct: if you add a module which is (indirectly) imported by DynFlags, you have to tell ghc.mk about it so that the Windows DLL splitting hack continues to work. Edward Excerpts from Simon Peyton Jones via ghc-devs's message of 2017-03-16 17:49:43 +: > If you add a module to GHC, I

Adding a module

If you add a module to GHC, I know you need to extend ghc.cabal.in. But also ghc.mk? Otherwise I get hits If you add a module to GHC, I know you need to extend ghc.cabal.in. But also ghc.mk? Otherwise I get hits /usr/bin/ar: creating rts/dist/build/libHSrts_debug.a Reachable modules from

Bounding I/O imprecision

Thinking more about this I/O demand analysis thing. I don't think it's possible for the compiler to decide for itself what to fuzz, but a user might know very well. Given m >>= f there are really two sensible approaches: 1. Want to ensure m is executed even if the action produced by f will