- ghc-devs - Haskell.org

Template Haskell working group
by Simon Peyton Jones 26 Jun '15

26 Jun '15

Friends I'm looking for someone, or a small group, to act as a Supreme Being for Template Haskell. Might you be willing? There is a steady trickle of bug reports / feature requests relating to Template Haskell, which I find that I simply don't have the time to pay proper attention to. Here is a recent example http://ghc.haskell.org/trac/ghc/ticket/10572. But if no one pays attention, they languish. None of them is very hard, but all require a little careful thought. What should the Template Haskell API be like? What semantics do we want? My hope is that if someone, or a small group, felt mandated to push TH forward, then we might make some progress. At the moment I have the uneasy feeling that while everyone can make suggestions, it's all waiting for SPJ to decide something, and SPJ is not paying enough attention. I don't want to be a bottleneck. Moreover, since I'm not a heavy-duty TH user, I'm poorly placed to make design choices. The reason I'm optimistic is because the steady trickle tells me that TH is in fact highly valued and widely used. So perhaps among that group there are some people who would be willing to debate alternative designs, make choices, and implement them. I would be more than willing to act as consultant, both on design and implementation. GHC absolutely relies on its community. Please consider making an offer to help. Thanks! Simon

2 3

RE: ANNOUNCE: GHC 7.10.2 Release Candidate 1
by Tamar Christina 21 Jun '15

21 Jun '15

For the Windows users: I have pushed GHC to the chocolatey package manager. You can find the packages including this rc1 here https://chocolatey.org/packages/ghc cinst ghc -pre To install it. The rest of the packages are still under moderation so until then you need to specify the full version of the one you want. Tamar Sent from my Windows Phone ------------------------------ From: Mark Lentczner <mark.lentczner(a)gmail.com> Sent: ‎6/‎15/‎2015 21:02 To: ghc-devs(a)haskell.org; haskell-platform(a)projects.haskell.org Subject: Re: ANNOUNCE: GHC 7.10.2 Release Candidate 1 And the Windows install for HP 7.10.2 RC1 is out too: HaskellPlatform-7.10.1.20150612-x86_64-setup.exe <http://www.ozonehouse.com/mark/platform/HaskellPlatform-7.10.1.20150612-x86…> 08c5f2168bdf9147b548263d2b45e1db6b602830002f27bbbbf92bf066b761f0 HaskellPlatform-7.10.1.20150612-x86_64-setup.exe

1 0

Re: [GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround
by George Colpitts 20 Jun '15

20 Jun '15

7.10.1.20150612 It's very sensitive, I see today. Sometimes it fails with Simplifier ticks exhausted other times it works. Bizarre I think the latter is the more common case and I think the former case has something to do with existing .o file or order of args and -fforce-recomp may mean it always works but that is very speculative. The two casesor $ time ghc -fno-specialise -O2 Slice.hs [1 of 1] Compiling Data.Array.Accelerate.CUDA.Array.Slice ( Slice.hs, Slice.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.1.20150612 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone $j_s1FS5 To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 1668604 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug real 0m19.714s user 0m18.264s sys 0m0.875s $ time ghc -O2 -fno-specialise Slice.hs [1 of 1] Compiling Data.Array.Accelerate.CUDA.Array.Slice ( Slice.hs, Slice.o ) real 0m3.228s user 0m3.040s sys 0m0.155s On Sat, Jun 20, 2015 at 2:03 PM, GHC <ghc-devs(a)haskell.org> wrote: > #10491: Regression, simplifier explosion with Accelerate, cannot compile, > increasing tick factor is not a workaround > -------------------------------------+------------------------------------- > Reporter: robertce | Owner: > Type: bug | Status: new > Priority: highest | Milestone: 7.10.2 > Component: Compiler | Version: 7.10.1 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: > Type of failure: Compile-time | Unknown/Multiple > performance bug | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Revisions: > -------------------------------------+------------------------------------- > > Comment (by bgamari): > > George, what GHC version did you test `-fno-specialise` on? While > yesterday I was able to confirm that `-fno-specialise` seemed to make no > difference on a test machine running what should have been 7.10.1 I am now > having trouble replicating this on my laptop. Unfortunately I no longer > have access to the test environment on which I tested this yesterday but > clearly something was inconsistent. > > I am now seeing on multiple machines that `-fno-specialise` indeed allows > things to compile, > {{{ > $ ghc -V > The Glorious Glasgow Haskell Compilation System, version 7.10.1 > $$ time ghc Slice.hs -fforce-recomp -O2 -fno-specialise > [1 of 1] Compiling Slice ( Slice.hs, Slice.o ) > > real 0m3.759s > user 0m1.688s > sys 0m0.044s > $ time ghc Slice.hs -fforce-recomp -O2 > [1 of 1] Compiling Slice ( Slice.hs, Slice.o ) > ^C > > real 0m51.103s > user 0m44.336s > sys 0m0.948s > }}} > > I am now looking at whether disabling only cross-module specialisation is > enough to eliminate the blow-up. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10491#comment:27> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

RFC: "Native -XCPP" Proposal
by Herbert Valerio Riedel 19 Jun '15

19 Jun '15

Hello *, As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension currently relies on the system's C-compiler bundled `cpp` program to provide a "traditional mode" c-preprocessor. This has caused several problems in the past, since parsing Haskell code with a preprocessor mode designed for use with C's tokenizer has caused already quite some problems[1] in the past. I'd like to see GHC 7.12 adopt an implemntation of `-XCPP` that does not rely on the shaky system-`cpp` foundation. To this end I've created a wiki page https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp to describe the actual problems in more detail, and a couple of possible ways forward. Ideally, we'd simply integrate `cpphs` into GHC (i.e. "plan 2"). However, due to `cpp`s non-BSD3 license this should be discussed and debated since affects the overall-license of the GHC code-base, which may or may not be a problem to GHC's user-base (and that's what I hope this discussion will help to find out). So please go ahead and read the Wiki page... and then speak your mind! Thanks, HVR [1]: ...does anybody remember the issues Haskell packages (& GHC) encountered when Apple switched to the Clang tool-chain, thereby causing code using `-XCPP` to suddenly break due to subtly different `cpp`-semantics?

15 19

RE: [Diffusion] [Build Failed] rGHCc45f8ceb0de0: Elaborate test for Trac #10403
by Simon Peyton Jones 19 Jun '15

19 Jun '15

I think 4945 is failing again -- although not on my machine. Can someone mark it expect_broken again? I'm on a train S | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 19 June 2015 00:09 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHCc45f8ceb0de0: Elaborate test for | Trac #10403 | | Harbormaster failed to build B4473: rGHCc45f8ceb0de0: Elaborate test for | Trac #10403! | | BRANCHES | master | | USERS | simonpj (Author) | GHC - Testsuite (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHCc45f8ceb0de0 | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Testsuite

2 1

missing file
by Simon Peyton Jones 18 Jun '15

18 Jun '15

I'm getting validate failures on HEAD. Missing file perhaps? Simon Unexpected failures: llvm/should_compile T8131b [exit code non-0] (optllvm) <command line>: does not exist: T8131b.cmm

1 0

RE: [commit: ghc] master: Update submodule process to master (c1dc421)
by Simon Peyton Jones 17 Jun '15

17 Jun '15

Thomas | Update submodule process to master | | This allows a warning free build on Windows, and thus an error free | validate. I was excited about this, because GHC has not validated on Windows for ages and ages. But I get the following failures, with HEAD, on 32-bit Windows. I can get more details if you like. I'd LOVE someone to fix these failures. thanks Simon Unexpected passes: driver T2507 (normal) driver T8959a (normal) rts T5250 (normal) rts rdynamic (normal) Unexpected failures: ../../libraries/base/tests/System Timeout001 [bad exit code] (normal) codeGen/should_compile T10518 [exit code non-0] (normal) codeGen/should_fail T8131 [stderr mismatch] (normal) ghci/scripts T5975a [bad stderr] (ghci) perf/haddock haddock.Cabal [[Errno 2] No such file or directory: './perf/haddock/../../../../libraries/Cabal/Cabal/dist-install/haddock.t'] (normal) perf/haddock haddock.base [[Errno 2] No such file or directory: './perf/haddock/../../../../libraries/base/dist-install/haddock.t'] (normal) perf/haddock haddock.compiler [[Errno 2] No such file or directory: './perf/haddock/../../../../compiler/stage2/haddock.t'] (normal) rts outofmem [bad stderr] (normal) Unexpected stat failures: perf/compiler T3294 [stat too good] (normal) perf/compiler T5030 [stat too good] (normal) perf/compiler T5837 [stat too good] (normal) perf/compiler T9961 [stat too good] (normal) perf/should_run T9203 [stat not good enough] (normal) perf/compiler T5321Fun [stat not good enough] (normal) perf/compiler T783 [stat not good enough] (normal) perf/compiler T9675 [stat not good enough] (optasm) perf/compiler T9872d [stat not good enough] (normal) | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 11 June 2015 18:30 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Update submodule process to master | (c1dc421) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/c1dc4216efc3db1a8fbd56a658981b5 | 3b7e42eda/ghc | | >--------------------------------------------------------------- | | commit c1dc4216efc3db1a8fbd56a658981b53b7e42eda | Author: Thomas Miedema <thomasmiedema(a)gmail.com> | Date: Thu Jun 11 19:24:25 2015 +0200 | | Update submodule process to master | | This allows a warning free build on Windows, and thus an error free | validate. | | | >--------------------------------------------------------------- | | c1dc4216efc3db1a8fbd56a658981b53b7e42eda | libraries/process | 2 +- | 1 file changed, 1 insertion(+), 1 deletion(-) | | diff --git a/libraries/process b/libraries/process | index 67efaf5..e0983fb 160000 | --- a/libraries/process | +++ b/libraries/process | @@ -1 +1 @@ | -Subproject commit 67efaf599a03f454a98a3905820ce40aa80825c7 | +Subproject commit e0983fbbfa8a3d81c7b99e83a3169fc686caab62 | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits

1 0

Re: [GHC] #10537: Parser: commas_tup_tail returns spurious "Missing" value
by Alan & Kim Zimmerman 17 Jun '15

17 Jun '15

So it appears the `Missing` item is correct, but it has been given the wrong SrcSpan. Originally it was a `noLoc`. I think I will just advance the column by one, then it is actually correct, and the annotation lookup will only succeed for the first one, so it will all just work. On Wed, Jun 17, 2015 at 5:14 PM, GHC <ghc-devs(a)haskell.org> wrote: > #10537: Parser: commas_tup_tail returns spurious "Missing" value > -------------------------------------+------------------------------------- > Reporter: alanz | Owner: alanz > Type: bug | Status: new > Priority: normal | Milestone: 7.10.2 > Component: Compiler | Version: 7.10.1 > (Parser) | Keywords: > Resolution: | Architecture: > Operating System: Unknown/Multiple | Unknown/Multiple > Type of failure: None/Unknown | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Revisions: > -------------------------------------+------------------------------------- > > Comment (by mpickering): > > I think you're right Simon. There is something wrong with the annotations > though, firstly both the Missing elements have the same SrcSpan `L > tests/examples/Tuple.hs:3:24`. > > {{{ > ((tests/examples/Tuple.hs:3:8, AnnComma), > [tests/examples/Tuple.hs:3:9]), > ((tests/examples/Tuple.hs:3:11-17, AnnComma), > [tests/examples/Tuple.hs:3:18]), > ((tests/examples/Tuple.hs:3:20-22, AnnComma), > [tests/examples/Tuple.hs:3:23]), > ((tests/examples/Tuple.hs:3:24, AnnComma), > [tests/examples/Tuple.hs:3:24]), > }}} > > Here are the relevant annotations. Notice how the first three commas are > associated with the preceding item (much like they are for lists) but the > last one is associated directly with the `Missing`. As both `Missing`s > have the same SrcSpan then this is causing duplicated output in `ghc- > exactprint`. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10537#comment:2> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

Validate failures on 7.10 branch
by Simon Peyton Jones 17 Jun '15

17 Jun '15

On a fresh build of the 7.10 branch, I get five validate failures on Linux. They are below. Is this only me? Simon Unexpected failures: driver T8959a [bad stderr] (normal) th T10279 [stderr mismatch] (normal) typecheck/should_fail T10534 [stderr mismatch] (normal) Unexpected stat failures: perf/should_run T4830 [stat not good enough] (normal) perf/should_run T7436 [stat not good enough] (normal)

2 2

MonadFail proposal (MFP): Moving fail out of Monad
by David Luposchainsky 17 Jun '15

17 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello *, the subject says it all. After we successfully put `=>` into Monad, it is time to remove something in return: `fail`. Like with the AMP, I wrote up the proposal in Markdown format on Github, which you can find below as a URL, and in verbatim copy at the end of this email. It provides an overview over the intended outcome, which design decisions we had to take, and how our initial plan for the transition looks like. There are also some issues left open to discussion. https://github.com/quchen/articles/blob/master/monad_fail.md Here's a short abstract: - - Move `fail` from `Monad` into a new class `MonadFail`. - - Code using failable patterns will receive a more restrictive `MonadFail` constraint. Code without this constraint will be safe to use for all Monads. - - Transition will take at least two GHC releases. GHC 7.12 will include the new class, and generate warnings asking users to make their failable patterns compliant. - - Stackage showed an upper bound of less than 500 breaking code fragments when compiled with the new desugaring. For more details, refer to the link or the paste at the end. Let's get going! David aka quchen =============================================================== =============================================================== =============================================================== `MonadFail` proposal (MFP) ========================== A couple of years ago, we proposed to make `Applicative` a superclass of `Monad`, which successfully killed the single most ugly thing in Haskell as of GHC 7.10. Now, it's time to tackle the other major issue with `Monad`: `fail` being a part of it. You can contact me as usual via IRC/Freenode as *quchen*, or by email to *dluposchainsky at the email service of Google*. This file will also be posted on the ghc-devs@ and libraries@ mailing lists, as well as on Reddit. Overview - -------- - - **The problem** - reason for the proposal - - **MonadFail class** - the solution - - **Discussion** - explaining our design choices - - **Adapting old code** - how to prepare current code to transition smoothly - - **Esimating the breakage** - how much stuff we will break (spoiler: not much) - - **Transitional strategy** - how to break as little as possible while transitioning - - **Current status** The problem - ----------- Currently, the `<-` symbol is unconditionally desugared as follows: ```haskell do pat <- computation >>> let f pat = more more >>> f _ = fail "..." >>> in computation >>= f ``` The problem with this is that `fail` cannot (!) be sensibly implemented for many monads, for example `State`, `IO`, `Reader`. In those cases it defaults to `error`. As a consequence, in current Haskell, you can not use `Monad`-polymorphic code safely, because although it claims to work for all `Monad`s, it might just crash on you. This kind of implicit non-totality baked into the class is *terrible*. The goal of this proposal is adding the `fail` only when necessary and reflecting that in the type signature of the `do` block, so that it can be used safely, and more importantly, is guaranteed not to be used if the type signature does not say so. `MonadFail` class - ----------------- To fix this, introduce a new typeclass: ```haskell class Monad m => MonadFail m where fail :: String -> m a ``` Desugaring can now be changed to produce this constraint when necessary. For this, we have to decide when a pattern match can not fail; if this is the case, we can omit inserting the `fail` call. The most trivial examples of unfailable patterns are of course those that match anywhere unconditionally, ```haskell do x <- action >>> let f x = more more >>> in action >>= f ``` In particular, the programmer can assert any pattern be unfailable by making it irrefutable using a prefix tilde: ```haskell do ~pat <- action >>> let f ~pat = more more >>> in action >>= f ``` A class of patterns that are conditionally failable are `newtype`s, and single constructor `data` types, which are unfailable by themselves, but may fail if matching on their fields is done with failable paterns. ```haskell data Newtype a = Newtype a - -- "x" cannot fail do Newtype x <- action >>> let f (Newtype x) = more more >>> in action >>= f - -- "Just x" can fail do Newtype (Just x) <- action >>> let f (Newtype (Just x)) = more more >>> f _ = fail "..." >>> in action >>= f ``` `ViewPatterns` are as failable as the pattern the view is matched against. Patterns like `(Just -> Just x)` should generate a `MonadFail` constraint even when it's "obvious" from the view's implementation that the pattern will always match. From an implementor's perspective, this means that only types (and their constructors) have to be looked at, not arbitrary values (like functions), which is impossible to do statically in general. ```haskell do (view -> pat) <- action >>> let f (view -> pat) = more more >>> f _ = fail "..." >>> in action >>= f do (view -> ~pat) <- action >>> let f (view -> ~pat) = more more >>> in action >>= f ``` A similar issue arises for `PatternSynonyms`, which we cannot inspect during compilation sufficiently. A pattern synonym will therefore always be considered failable. ```haskell do PatternSynonym x <- action >>> let f PatternSynonym x = more more >>> in f _ = fail "..." >>> in action >>= f ``` Discussion - ---------- - - Although for many `MonadPlus` `fail _ = mzero`, a separate `MonadFail` class should be created instead of just using that. - A parser might fail with an error message involving positional information. Some libraries, like `Binary`, provide `fail` as their only interface to fail a decoding step. - Although `STM` is `MonadPlus`, it uses the default `fail = error`. It will therefore not get a `MonadFail` instance. - - What laws should `fail` follow? **Left zero**, ```haskell ∀ s f. fail s >>= f ≡ fail s ``` A call to `fail` should abort the computation. In this sense, `fail` would become a close relative of `mzero`. It would work well with the common definition `fail _ = mzero`, and give a simple guideline to the intended usage and effect of the `MonadFail` class. - - Rename `fail`? **No.** Old code might use `fail` explicitly and we might avoid breaking it, the Report talks about `fail`, and we have a solid migration strategy that does not require a renaming. - - Remove the `String` argument? **No.** The `String` might help error reporting and debugging. `String` may be ugly, but it's the de facto standard for simple text in GHC. No high performance string operations are to be expected with `fail`, so this breaking change would in no way be justified. Also note that explicit `fail` calls would break if we removed the argument. - - How sensitive would existing code be to subtle changes in the strictness behaviour of `do` notation pattern matching? **It doesn't.** The implementation does not affect strictness at all, only the desugaring step. Care must be taken when fixing warnings by making patterns irrefutable using `~`, as that *does* affect strictness. (Cf. difference between lazy/strict State) - - The `Monad` constraint for `MonadFail` seems unnecessary. Should we drop or relax it? What other things should be considered? - Applicative `do` notation is coming sooner or later, `fail` might be useful in this more general scenario. Due to the AMP, it is trivial to change the `MonadFail` superclass to `Applicative` later. (The name will be a bit misleading, but it's a very small price to pay.) - The class might be misused for a strange pointed type if left without any constraint. This is not the intended use at all. I think we should keep the `Monad` superclass for three main reasons: - We don't want to see `(Monad m, MonadFail m) =>` all over the place. - The primary intended use of `fail` is for desugaring do-notation anyway. - Retroactively removing superclasses is easy, but adding them is hard (see AMP). Adapting old code - ----------------- - - Help! My code is broken because of a missing `MonadFail` instance! *Here are your options:* 1. Write a `MonadFail` instance (and bring it into scope) ```haskell #if !MIN_VERSION_base(4,11,0) -- Control.Monad.Fail import will become redundant in GHC 7.16+ import qualified Control.Monad.Fail as Fail #endif import Control.Monad instance Monad Foo where (>>=) = <...bind impl...> -- NB: `return` defaults to `pure` #if !MIN_VERSION_base(4,11,0) -- Monad(fail) will be removed in GHC 7.16+ fail = Fail.fail #endif instance MonadFail Foo where fail = <...fail implementation...> ``` 2. Change your pattern to be irrefutable 3. Emulate the old behaviour by desugaring the pattern match by hand: ```haskell do Left e <- foobar stuff ``` becomes ```haskell do x <- foobar e <- case foobar of Left e' -> e' Right r -> error "Pattern match failed" -- Boooo stuff ``` The point is you'll have to do your dirty laundry yourself now if you have a value that *you* know will always match, and if you don't handle the other patterns you'll get incompleteness warnings, and the compiler won't silently eat those for you. - - Help! My code is broken because you removed `fail` from `Monad`, but my class defines it! *Delete that part of the instance definition.* Esimating the breakage - ---------------------- Using our initial implementation, I compiled stackage-nightly, and grepped the logs for found "invalid use of fail desugaring". Assuming my implementation is correct, the number of "missing `MonadFail`" warnings generated is 487. Note that I filtered out `[]`, `Maybe` and `ReadPrec`, since those can be given a `MonadFail` instance from within GHC, and no breakage is expected from them. The build logs can be found [here][stackage-logs]. Search for "failable pattern" to find your way to the still pretty raw warnings. Transitional strategy - --------------------- The roadmap is similar to the [AMP][amp], the main difference being that since `MonadFail` does not exist yet, we have to introduce new functionality and then switch to it. * **GHC 7.12 / base-4.9** - Add module `Control.Monad.Fail` with new class `MonadFail(fail)` so people can start writing instances for it. `Control.Monad` only re-exports the class `MonadFail`, but not its `fail` method. NB: At this point, `Control.Monad.Fail.fail` clashes with `Prelude.fail` and `Control.Monad.fail`. - *(non-essential)* Add a language extension `-XMonadFail` that changes desugaring to use `MonadFail(fail)` instead of `Monad(fail)`. This has the effect that typechecking will infer a `MonadFail` constraint for `do` blocks with failable patterns, just as it is planned to do when the entire thing is done. - Warn when a `do`-block that contains a failable pattern is desugared, but there is no `MonadFail`-instance in scope: "Please add the instance or change your pattern matching." Add a flag to control whether this warning appears. - Warn when an instance implements the `fail` function (or when `fail` is imported as a method of `Monad`), as it will be removed from the `Monad` class in the future. (See also [GHC #10071][trac-10071]) 3. GHC 7.14 - Switch `-XMonadFail` on by default. - Remove the desugaring warnings. 3. GHC 7.16 - Remove `-XMonadFail`, leaving its effects on at all times. - Remove `fail` from `Monad`. - Instead, re-export `Control.Monad.Fail.fail` as `Prelude.fail` and `Control.Monad.fail`. - `Control.Monad.Fail` is now a redundant module that can be considered deprecated. Current status - -------------- - - [ZuriHac 2015 (29.5. - 31.5.)][zurihac]: Franz Thoma (@fmthoma) and me (David Luposchainsky aka @quchen) started implementing the MFP in GHC. - Desugaring to the new `fail` can be controlled via a new langauge extension, `MonadFailDesugaring`. - If the language extension is turned off, a warning will be emitted for code that would break if it was enabled. - Warnings are emitted for types that *have* a *MonadFail* instance. This still needs to be fixed. - The error message are readable, but should be more so. We're still on this. - - 2015-06-09: Estimated breakage by compiling Stackage. Smaller than expected. [amp]: https://github.com/quchen/articles/blob/master/applicative_monad.md [stackage-logs]: https://www.dropbox.com/s/knz0i979skam4zs/stackage-build.tar.xz?dl=0 [trac-10071]: https://ghc.haskell.org/trac/ghc/ticket/10071 [zurihac]: https://wiki.haskell.org/ZuriHac2015 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVd0/yAAoJELrQsaT5WQUshbUH/A3W0itVAk7ao8rtxId5unCJ 7StriKVkTyLAkkrbRJngM4MHEKiCsoyIgr8kBIwSHgk194GxeP2NCF4ijuBZoDBt +Uci+6BCBinV8+OzfrfTcJb4+8iw1j+eLWJ/Nz/JDMDNCiyzyC0SMsqGa+ssOz7H /2mqPkQjQgpHuP5PTRLHKPPIsayCQvTbZR1f14KhuMN2SPDE+WY4rqugu//XuIkN u1YssIf5l8mEez/1ljaqGL55cTI0UNg2z0iA0bFl/ajHaeQ6mc5BAevWfSohAMW7 7PIt13p9NIaMHnikmI+YJszm2IEaXuv47mGgbyDV//nHq3fwWN+naB+1mPX2eSU= =vPAL -----END PGP SIGNATURE-----

14 24