- ghc-devs - Haskell.org

MIN_VERSION macros
by David Feuer 22 Oct '15

22 Oct '15

Cabal defines MIN_VERSION_* macros that allow CPP in a Haskell source file to get information about the versions of the packages that module is being compiled against. Unfortunately, these macros are not available when not compiling with cabal, so packages must either 1. Insist on cabal compilation. This is not very friendly to developers. 2. Make "pessimistic" assumptions, assuming that all the packages are old. This makes it annoying to test new features while also leading to compilation or run-time failures when packages have removed it changed features. 3. Attempt to guess the version based on the GHC version. This works reasonably well for base, ghc-prim, containers, etc., but not so well/at all for others. Would there be some way to get GHC itself to provide these macros to all modules that request CPP? David Feuer

6 7

Memory fence around stg_atomicModifyMutVarzh
by Michael Walker 21 Oct '15

21 Oct '15

Hello, I've been trying to figure out where exactly the synchronisation guarantee of `atomicModifyIORef` comes from, I've gone down a bit of a rabbit-hole of function calls and macro expansions, and wanted to check I'd got the right idea. **Assumption:** `stg_atomicModifyMutVarzh` imposes a barrier to reordering, as described in the Data.IORef documentation. Call tree: stg_atomicModifyMutVarzh dirty_MUT_VAR recordClosureMutated recordMutableCap allocBlock_lock ACQUIRE_SM_LOCK -> ACQUIRE_LOCK -> pthread_mutex_lock **Conclusion:** `pthread_mutex_lock` imposes a memory barrier, and it is through this rather indirect chain of function calls that `stg_atomicModifyMutVarzh` gets its barrier property. Is this correct? Or is there a more direct barrier invocation that I have missed? Thanks. -- Michael Walker (http://www.barrucadu.co.uk)

4 4

pattern synonym with required ctx having polykinded constraint fails
by Sreenidhi Nair 21 Oct '15

21 Oct '15

Hello, We have a pattern synonym as follows type family Showable (a :: k) :: Constraint where Showable (a :: *) = (Show a) Showable a = () pattern Just' :: () => (Showable a) => a -> (Maybe a) pattern Just' a <- (extractJust -> (True, a)) where Just' a = Just a When we try to use the pattern in a different package, the error was [1 of 1] Compiling Bar ( Bar.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Bar.o ) /tmp/test/p2/.stack-work/install/x86_64-linux/lts-3.5/7.10.2/lib/x86_64-linux-ghc-7.10.2/p1-0.1.0.0-I5t4il6dN7vIqsT1XgYsM3/Foo.hi Declaration for Just' Pattern synonym Just': Iface type variable out of scope: k Cannot continue after interface file error The error only occurred when Showable was polykinded and we used synonym in a different package . Using the synonym in the same package works fine. This problem did not happen with the following definition of (non polykinded ) Showable type family Showable a :: Constraint where Showable a = (Show a) We have attached the sample packages which simulate the exact scenario described above. -- Yours truly, Sreenidhi Nair

2 2

Re: [Differential] [Closed] D975: ELF/x86_64: map object file sections separately into the low 2GB
by Thomas Miedema 21 Oct '15

21 Oct '15

This commit is causing segmentation faults on Travis (DYNAMIC_GHC_PROGRAMS = NO): https://s3.amazonaws.com/archive.travis-ci.org/jobs/85552765/log.txt Unexpected failures: ghci.debugger/scripts break001 [bad exit code] (ghci) ghci.debugger/scripts break005 [bad exit code] (ghci) ghci.debugger/scripts break006 [bad exit code] (ghci) ghci.debugger/scripts break011 [bad exit code] (ghci) ghci.debugger/scripts break017 [bad exit code] (ghci) ghci.debugger/scripts dynbrk007 [bad exit code] (ghci) ghci.debugger/scripts hist001 [bad exit code] (ghci) ghci.debugger/scripts print001 [bad exit code] (ghci) ghci.debugger/scripts print002 [bad exit code] (ghci) ghci.debugger/scripts print003 [bad exit code] (ghci) ghci.debugger/scripts print004 [bad exit code] (ghci) ghci.debugger/scripts print005 [bad exit code] (ghci) ghci.debugger/scripts print006 [bad exit code] (ghci) ghci.debugger/scripts print008 [bad exit code] (ghci) ghci.debugger/scripts print010 [bad exit code] (ghci) ghci.debugger/scripts print011 [bad exit code] (ghci) ghci.debugger/scripts print012 [bad exit code] (ghci) ghci.debugger/scripts print013 [bad exit code] (ghci) ghci.debugger/scripts print016 [bad exit code] (ghci) ghci.debugger/scripts print017 [bad exit code] (ghci) ghci.debugger/scripts print019 [bad exit code] (ghci) ghci.debugger/scripts print020 [bad exit code] (ghci) ghci.debugger/scripts print023 [bad exit code] (ghci) ghci.debugger/scripts print024 [bad exit code] (ghci) ghci.debugger/scripts print026 [bad exit code] (ghci) ghci.debugger/scripts print028 [bad exit code] (ghci) ghci.debugger/scripts print031 [bad exit code] (ghci) ghci.debugger/scripts print032 [bad exit code] (ghci) ghci.debugger/scripts print034 [bad exit code] (ghci) ghci/scripts T2976 [bad exit code] (ghci) On Thu, Oct 15, 2015 at 5:20 PM, simonmar (Simon Marlow) < noreply(a)phabricator.haskell.org> wrote: > This revision was automatically updated to reflect the committed changes. > Closed by commit rGHC04e8366608fe: ELF/x86_64: map object file sections > separately into the low 2GB (authored by simonmar). > > *CHANGED PRIOR TO COMMIT* > https://phabricator.haskell.org/D975?vs=4501&id=4502#toc > > *REPOSITORY* > rGHC Glasgow Haskell Compiler > > *CHANGES SINCE LAST UPDATE* > https://phabricator.haskell.org/D975?vs=4501&id=4502 > > *REVISION DETAIL* > https://phabricator.haskell.org/D975 > > *AFFECTED FILES* > rts/CheckUnload.c > rts/Linker.c > rts/LinkerInternals.h > testsuite/tests/ghci/linking/all.T > testsuite/tests/rts/linker_error.c > > *EMAIL PREFERENCES* > https://phabricator.haskell.org/settings/panel/emailpreferences/ > > *To: *simonmar, Phyx, trommler, bgamari, austin > *Cc: *hsyl20, thomie, bgamari >

2 1

Show instances for GHC internals
by Ömer Sinan Ağacan 20 Oct '15

20 Oct '15

Currently the only way to debug and inspect GHC internals is by adding some carefully placed print statements. (I'd love to be proven wrong on this, cost of debugging this way is huge, given how long it's taking to rebuild GHC) We have Outputable instances for most data types, and `Outputable.pprTrace` etc. helps with debugging/inspecting pure functions this way. However, Outputable instances are hiding some details and they're sometimes not useful for debugging and inspecting internals. This is why I implemented CoreDump package(http://hackage.haskell.org/package/CoreDump), Outputable instance of CoreSyn is simply not useful for some things. Similarly, just today I had to add a show function for `HscTypes.TargetId` because `Outputable` instance was hiding `Maybe Phase` field. Since the only way to debug or inspect GHC internals(except maybe the RTS) is by printing things, I think we should provide Show instances for.. basically everything. Otherwise I just can't see a way of debugging things and inspecting internals, tracing code etc. for learning purposes. I was wondering what would be the cost of adding Show instances. Would that mean significantly increased compile times? Or significantly bigger GHC binaries? If that's the case, could we enable Show instances with some arguments so that we can enable/disable it by modifying mk/build.mk?

4 6

Taking a step back
by Johan Tibell 20 Oct '15

20 Oct '15

Friends, I'm taking a step back from day-to-day library work. There are two main reasons I use Haskell: on one hand I find writing Haskell educational and fun. On the other I hope to make it a viable alternative to existing mainstream languages. With recent changes to our core libraries, and the general direction these are moving in, I believe we're moving away from becoming a viable alternative to those mainstream languages. This has some practical implications for how I spend my Haskell hacking time. Much of what I do is maintaining and working on libraries that are needed for real world usage, but that aren't that interesting to work on. I've lost the motivation to work on these. I've decided to take a step back from the core maintenance work on cabal, network, containers, and a few others* starting now. I've already found replacement maintainers for these. I still plan to hack on random side projects, including GHC, and to continue coming to Haskell events and conference, just with a shorter bug backlog to worry about. :) -- Johan Tibell * For now I will still hack on unordered-containers and ekg, as there are some things I'd like to experiment with there.

4 3

is this change in TH error message intentional?
by Ömer Sinan Ağacan 20 Oct '15

20 Oct '15

Hi all, I realized this change in TH error messages: GHC 7.10.2: ➜ th-test ghc --make Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:13:15: Not in scope: ‘locaton’ Perhaps you meant ‘location’ (imported from Language.Haskell.TH.Syntax) In the splice: $locaton Main.hs:13:15: GHC stage restriction: ‘locaton’ is used in a top-level splice or annotation, and must be imported, not defined locally In the expression: locaton In the splice: $locaton I think both error messages are quite useful in this context. I don't see second one as redundant. However, with HEAD: ➜ th-test ghc-stage2 --make Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:13:15: error: Variable not in scope: locaton :: ExpQ Perhaps you meant ‘location’ (imported from Language.Haskell.TH.Syntax) I think this new message is quite worse than previous one. First, "In the splice ..." part is missing. Second, "It must be imported, not defined locally" message is not given at all. Was this change intentional? May I ask why it's changed?

3 3

Building stage1 only
by Ömer Sinan Ağacan 20 Oct '15

20 Oct '15

(I know I asked this many times in IRC channel but I don't remember getting any answers. I apologize if anyone had answered this on IRC channel and I missed) With current build system, even if I choose "devel1" it always builds stage2 compiler too. A comment in build.mk says that it's for working on stage1 compiler, so I'd expect it to build only stage1. The reason I want stage1-only builds is the time it takes to build both stages. It takes approximately 30 minutes and if I could reduce this down to half that would greatly improve my work flow. Most of the time I don't need a full build, but in my experience, it's very easy to end up in a state where `make` simply can't build, and only easy fix is a `make clean`, which costs 30 minutes because then I have to build from scratch. This happens way too often, and so I need a stage1-only build. Thanks..

4 5

Confusing error message when universally quantifying unused type variables
by Alexander Berntsen 20 Oct '15

20 Oct '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 In Set theory sentence construction, if the letter is not used then no foul. In Haskell, it is not always so. The following is well-typed and works happily: f :: Eq a => b -> b f b = b However, this does not work: f :: ∀ a. Eq a => b -> b f b = b It will result in the error "Not in scope: type variable ‘b’" being spat out twice. Is this error message really desirable? If there is no principled reason for this result, may I suggest improving it? I can conceivably see some codebase using RankNTypes exclusively having a typo like f :: ∀ a. b -> b f b = b Consequently the error message should be more precise. Furthermore the first code snippet I gave also strikes me as nonsensical; if someone has code like that, it is probably the result of a typo. Should we really permit it? Is there a motivating reason for permitting it? If no, I suggest it be an error. (My understanding of the 2010 report was that it *isn't* permitted, but perhaps I read it wrong.) - -- Alexander alexander(a)plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWJiE0AAoJENQqWdRUGk8BVmYP/0yhrfFs8LHLUAhGnza3f6Xx uFJQdvMmZcSLQQZxFyBvVcNwAK0x1ntnT+jeG/Q0j1oQns6EoWkJ9WzBQIxVQ2+O 9bm45N+gX1K1W1Z0WEX+LCPszntLMvBdp6C3Wp4ff+XvS9e0uHTqftDdD3iUexPA K5wTB5qs+3IWVFEyyPIuJpOqOLhTy9FMct9Ls4m72Uu3FIWPEgjANuT/WkkLASXP Av+qn0hTUzmoNf2nWcjvJQIZvgM6xfpJleWlO2CinOuPunZiackja/qTGlvx7Pu6 Yo5Fs2WdfCB1yx3iPnDcSrJ3pQcZkLqVsGRNdEXdQEHMH1icLR15Z7ynpKkI6uBb JI+vAyq//NbdbRUOPzwN/PA+kGczUTBhTeAnwB5194fdzlfmH9vDsdN8p4CPtsTG 3T3u5EEyn8a/v0nQPssDEfli8Mx4uOswQmTsLgJCJ1H94FbNdGS3R98NmM63A9II rN53o16m6z4C27YQL4q84LwbnWvOEyE9s3xBZMd8hsbTdb7F2syVoSYZazgP5PGc uv/pAwKqwkGU53yBBhj+RqfPXk3qf0bOHtsercIAhnmkIAjI5l7bdxmDyhW4aj49 pWRJgOPAAlQ+VriFoodMZ9PD42pvxUlzicDfvpELVpviHdlTrovky9UC+buCFrtG 7k9GmyHqe/B3LyDjxbh+ =jerq -----END PGP SIGNATURE-----

2 3

Moving forall with coerce
by David Feuer 20 Oct '15

20 Oct '15

It appears, as far as I can tell, that GHC can't move a forall past an -> with coerce. I was playing around with the MonadTrans instance for Codensity, wanting (essentially) to write lift = coerce (>>=) This is legal: instance MonadTrans Codensity where lift = frob frob :: forall m a . Monad m => m a -> Codensity m a frob = coerce (blah (Mag (>>=)) :: m a -> Mag2 m a) newtype Mag m a = Mag (forall b . m a -> (a -> m b) -> m b) newtype Mag2 m a = Mag2 (forall b . (a -> m b) -> m b) blah :: Mag m a -> m a -> Mag2 m a blah (Mag p) q = Mag2 (p q) The problem is that there doesn't *seem* to be a way to implement blah as a coercion. GHC doesn't recognize that Mag m a has the same representation as m a -> Mag2 m a The essential difference, as far as I can see, is that the `forall b` is shifted across `m a ->`. It seems that this really shouldn't be an issue, because 1. b is not free in `m a` 2. Type lambdas all compile away Would it be worth trying to extend the Coercible mechanism to deal with these kinds of situations? Or is there already some way to do it that I've missed? David

3 2