- ghc-devs - Haskell.org

LLVM failures
by Simon Peyton Jones 04 Mar '15

04 Mar '15

These two LLVM tests are still failing consistently for me (on Linux). I think Austin said this should not happen, and he would fix, but I can't find the thread. Anyway, what should I do? Simon <no location info>: You are using an old version of LLVM that isn't supported anymore! We will try though... /usr/bin/opt: /tmp/ghc60014_1/ghc60014_2.ll:7:6: error: expected type !0 = !{!"top", i8* null} Unexpected failures: llvm/should_compile T5681 [exit code non-0] (optllvm) llvm/should_compile T7571 [exit code non-0] (optllvm)

4 5

Windows build broken
by Simon Peyton Jones 04 Mar '15

04 Mar '15

AAARGH! Windows build is broken again. Please can someone fix? In file included from rts\RtsMain.c:12:0: rts\PosixSource.h:31:0: error: "__USE_MINGW_ANSI_STDIO" redefined c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/_mingw.h:280:0: note: this is the location of the previous definition rts/ghc.mk:243: recipe for target 'rts/dist/build/RtsMain.o' failed make[1]: *** [rts/dist/build/RtsMain.o] Error 1

3 4

GHC Weekly News - 2015/03/03
by Austin Seipp 04 Mar '15

04 Mar '15

(This post is available online at https://ghc.haskell.org/trac/ghc/blog/weekly20150303) Hi *, It's that time again! Today GHC HQ met on a Tuesday to avoid some scheduling conflicts, and that means it's time to send some news to people. Just a quick reminder from last week: we're hoping to make our third GHC 7.10.1 release candidate on '''Friday, March 13th''', with the final release on '''Friday, March 27th'''. Today, GHC HQ met up and mostly discussed the current status of GHC 7.10 and its bugs, which you can find on the Status page: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 But we've also had a little more list activity this week than we did before: - Simon PJ showed up to tell everyone he'd be a bit busy due to upcoming ICFP deadlines! However, since it's passed as of last Friday, it looks like the coming weeks will be more normal. https://mail.haskell.org/pipermail/ghc-devs/2015-February/008420.html - Michael Snoyman started a thread about a serious bug that has eluded attention during the 7.10 RC period: `cabal haddock --hoogle` does not work! https://mail.haskell.org/pipermail/ghc-devs/2015-February/008412.html - Jan Bracker is working on using the new type-checking plugins infrastructure, and had a question about the usage of what the typechecker calls `EvTerms`. Adam swooped in to respond. https://mail.haskell.org/pipermail/ghc-devs/2015-February/008414.html - Ben Gamari has been working on #9661, but while trying to do so hit a very painful set of conditions due to the import dependency graph of the compiler, making his fix much more difficult. Simon responds with his thoughts. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008432.html - After returning from an ICFP-writing-induced hiatus, Simon alerted us to a new paper of his describing his new, GADT-aware pattern matching checker. As usual, he'd love comments! The implementation will hopefully land in HEAD soon. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008437.html - Nikita Karetnikov was kind enough to alert the list that he's gotten a nice, Nix/NixOS based solution to building GHC, which he's documented on the wiki. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008445.html Some noteworthy commits that went into `ghc.git` in the past week include: - Commit aead01902e1c41e85b758dbafd15e60d08956374 - the `-fwarn-unused-binds` warning was split into 3 warnings, fixing #17 (one of our oldest open tickets). - Commit 5be8ed4da1963ed2d45a65fb61d761c977707cce - restores `integer-gmp` compatibility with GMP 4.x. This will be part of GHC 7.10. - Commit 31d4f2e9c89e22a91f98b4a4aa0f80af6b07b60f - `make test` in the top-level directory now works as expected. - Commit 5200bdeb26c5ec98739b14b10fc8907296bceeb9 - Replace Windows SEH handlers with VEH handlers, working uniformly across x86 and x86_64. Closed tickets the past week include: #9586, #10122, #10026, #8896, #10090, #10123, #10128, #10025, #10024, #10125, #9994, #9962, #10103, #10112, #10122, #9901, #10130, #10129, #9044, #8342, #8780, #10003, #17, #2530, #8274, and #10107. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Re: Hoopl and Arrows
by John Lato 03 Mar '15

03 Mar '15

Thomas, I'd be very careful mixing effectful arrows with the CCA framework. Effectful arrows are not necessarily commutative, so the CCA transformations may be invalid. I did something very similar a couple years ago, by creating an arrow instance that generated TH expressions. IME the ghc optimizer handled it extremely well, and no extra optimizations were necessary. John L. On 14:43, Mon, Mar 2, 2015 Justin Bailey <jgbailey(a)gmail.com> wrote: > Thomas, > > I did some stuff with Hoopl a few years ago as part of my Master's > thesis ("Using Dataflow Optimization Techniques with a Monadic > Intermediate Language"). In Chapter 3 ("The Hoopl Library"), I wrote > up an overview of Hoopl and work through a new example (new at the > time, at least). > > You can download my thesis from http://mil.codeslower.com. The example > code from that chapter is available at > https://github.com/m4dc4p/mil/blob/master/thesis/DeadCodeC.lhs. No > guarantees that it still compiles, but I'm glad to try and help needed > :) > > > On Mon, Mar 2, 2015 at 1:34 PM, Simon Peyton Jones > <simonpj(a)microsoft.com> wrote: > > Thomas > > > > > > > > Hoopl works on control flow graphs, whereas Core is lambda calculus. I > > really don’t think Hoopl is going to be any good for optimising Core. > > > > > > > > Ask the ghc-devs mailing list too. Someone there has been writing about > > arrows recently (take a look at the archive). > > > > > > > > Simon > > > > > > > > From: Thomas Bereknyei [mailto:tomberek@gmail.com] > > Sent: 02 March 2015 17:07 > > To: nr(a)cs.tufts.edu; Simon Peyton Jones > > Subject: Hoopl and Arrows > > > > > > > > I've been interested in Arrows and their optimization recently. I've run > > into problems during basic tooling so I built a quasiquoter for proc > > notation (still working on rec and let statements, but the rest of it > works) > > that converts from haskell-src-exts into a desugarred TH format. My > original > > goal was to implement "Casual Commutative Arrows" [1] but to make it > more > > user friendly and to include arrows with effects. I came across Hoopl > and at > > first glance I would think it can help with Arrow optimization, > especially > > with the tuple shuffling from desuggared proc-do notation. In spite of > the > > slogan of "Hoopl: Dataflow Optimization made Simple" and the git repo's > > testing folder, I'm not 100% clear on Hoopl usage. I would be interested > in > > anything that can get me started or even a thought or two whether it > would > > be worth looking into for Arrows. > > > > Simon, regarding [2], my quasiquoter can be rewritten to take `bind`, > > `bind_`, `fixA`, and `ifThenElseA` from scope rather than being built in. > > Would that help with #7828? I am not very familiar with GHC internals at > > the moment, and I am confused about the complexity of dsArrows.hs in > > contrast with my own parser. It seems I have a good start on it in the > > Parser module at [3], WARNING: untested and rough draft code, though > > suggestions and pointers are welcome. I was thinking of sending some of > my > > code to haskell-src-meta because they can't yet translate their version > of > > Exp into TH's ExpQ. > > > > -Tom > > > > > > [1] (https://hackage.haskell.org/package/CCA) > > [2] (https://ghc.haskell.org/trac/ghc/ticket/7828#comment:54) > > [3] (https://www.fpcomplete.com/user/tomberek/rulestesting) > > > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs(a)haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >

1 0

PSA: building HEAD with Nix/NixOS
by Nikita Karetnikov 03 Mar '15

03 Mar '15

I've just added instructions showing how easy it is to build GHC HEAD and its dependencies with Nix/NixOS: https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Linux#NixNixOS I hope someone finds them useful.

1 0

Heads up: top level `make test` now runs the full testsuite
by Thomas Miedema 03 Mar '15

03 Mar '15

Typing `make test` in the ghc root directory now runs the full testsuite, just like it already did in the `testsuite/tests` directory. If you want to run the fast testsuite, use the new targets `make fasttest` or `make fast`. The `validate` script still runs the same tests as before (depending on the argument, `--slow`, `--fast` or normal). References: https://ghc.haskell.org/trac/ghc/wiki/Building/StandardTargets#Topleveltarg… https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests -Thomas Miedema

2 2

RE: Hoopl and Arrows
by Simon Peyton Jones 02 Mar '15

02 Mar '15

Thomas Hoopl works on control flow graphs, whereas Core is lambda calculus. I really don’t think Hoopl is going to be any good for optimising Core. Ask the ghc-devs mailing list too. Someone there has been writing about arrows recently (take a look at the archive). Simon From: Thomas Bereknyei [mailto:tomberek@gmail.com] Sent: 02 March 2015 17:07 To: nr(a)cs.tufts.edu; Simon Peyton Jones Subject: Hoopl and Arrows I've been interested in Arrows and their optimization recently. I've run into problems during basic tooling so I built a quasiquoter for proc notation (still working on rec and let statements, but the rest of it works) that converts from haskell-src-exts into a desugarred TH format. My original goal was to implement "Casual Commutative Arrows" [1] but to make it more user friendly and to include arrows with effects. I came across Hoopl and at first glance I would think it can help with Arrow optimization, especially with the tuple shuffling from desuggared proc-do notation. In spite of the slogan of "Hoopl: Dataflow Optimization made Simple" and the git repo's testing folder, I'm not 100% clear on Hoopl usage. I would be interested in anything that can get me started or even a thought or two whether it would be worth looking into for Arrows. Simon, regarding [2], my quasiquoter can be rewritten to take `bind`, `bind_`, `fixA`, and `ifThenElseA` from scope rather than being built in. Would that help with #7828? I am not very familiar with GHC internals at the moment, and I am confused about the complexity of dsArrows.hs in contrast with my own parser. It seems I have a good start on it in the Parser module at [3], WARNING: untested and rough draft code, though suggestions and pointers are welcome. I was thinking of sending some of my code to haskell-src-meta because they can't yet translate their version of Exp into TH's ExpQ. -Tom [1] (https://hackage.haskell.org/package/CCA) [2] (https://ghc.haskell.org/trac/ghc/ticket/7828#comment:54) [3] (https://www.fpcomplete.com/user/tomberek/rulestesting)

2 1

Fwd: EvTerms and how they are used
by Jan Bracker 02 Mar '15

02 Mar '15

Hi Adam, thank you for your quick and detailed answer! I think I understand how to construct evidence for typeclass constraints now. But trying to apply this, I still have some problems. I have something along the following lines: class Polymonad m n p where -- Functions instance Polymonad Identity Identity Identity where -- Implementation -- Further instances and some small chunk of code involving them: The code implies the following constraint: Polymonad Identity n_abpq Identity As the ambiguity error I get says, when trying to compile this: There is only one matching instance (the one above, lets call it $fPolymonadIdentityIdentityIdentity). So my plugin tries to tell GHC to use that instance. As far as I understand it, since the parameters of $fPolymonadIdentityIdentityIdentity are no type variables and there is no superclass it should be as easy as saying: EvDFunApp $fPolymonadIdentityIdentityIdentity [] [] But when I run this with -dcore-lint I get the following error message: *** Core Lint errors : in result of Desugar (after optimization) *** <no location info>: Warning: In the expression: >> @ Identity @ Any @ Identity $fPolymonadIdentityIdentityIdentity @ () @ () (idOp @ Bool True) (>>= @ Identity @ Identity @ Any $fPolymonadIdentityIdentityIdentity @ Char @ () (return @ Char @ Identity $fPolymonadIdentityIdentityIdentity (C# 'a')) (\ _ [Occ=Dead] -> return @ () @ Identity $fPolymonadIdentityIdentityIdentity ())) Argument value doesn't match argument type: Fun type: Polymonad Identity Any Identity => forall a_abdV[sk] b_abdW[sk]. Identity a_abdV[sk] -> Any b_abdW[sk] -> Identity b_abdW[sk] Arg type: Polymonad Identity Identity Identity Arg: $fPolymonadIdentityIdentityIdentity What am I missing? Why doesn't the argument type "Polymonad Identity Identity Identity" match the first argument of the function type "Polymonad Identity Any Identity => forall a_abdV[sk] b_abdW[sk]. Identity a_abdV[sk] -> Any b_abdW[sk] -> Identity b_abdW[sk]". Why is the type variable translated to "Any"? Best, Jan 2015-02-25 13:35 GMT+00:00 Adam Gundry <adam(a)well-typed.com>: > Hi Jan, > > Yes, unfortunately the meaning of EvTerm is a weak point of the current > typechecker plugins story; it rather requires one to understand how > GHC's constraint solver produces evidence. There are lots of papers on > evidence for equality constraints in System FC, but typeclass > constraints are generally ignored as they are just datatypes at the FC > level. > > Let me try to give you some idea of what EvDFunApp means, then hopefully > those with more knowledge of the GHC internals can correct me... > > If you write a class instance, e.g. > > instance (Show a, Show b) => Show (T a b) where ... > > then GHC generates a dfun (short for "dictionary function", I guess) > > $fShowT :: forall a b . (Show a, Show b) => Show (T a b) > > where Show is treated as a record data type containing a dictionary of > methods for the class. At the core level, this is a normal term-level > function (albeit with a strange name). > > Now when the typechecker has a constraint to solve, say > > Show (T Int Bool), > > it produces evidence for this by applying $fShowT to the appropriate > types and to evidence for the superclass constraints, in this case > something like > > $fShowT @Int @Bool $fShowInt $fShowBool > > where I'm using @ for type application. This is represented in EvTerm as > > EvDFunApp $fShowT [Int, Bool] [ EvDFunApp $fShowInt [] [] > , EvDFunApp $fShowBool [] [] ] > > Thus the [Type] is the list of kinds/types at which to instantiate the > dfun, and the [EvTerm] is the list of evidence terms to which it must be > applied. Obviously this application should be well-typed, and > -dcore-lint will complain if it is not. > > For typechecker plugins, it would be nice if we could write arbitrary > core expressions as evidence, but this hasn't yet been implemented > (partially because most of the examples so far solve equality > constraints, rather than typeclass constraints). > > Hope this helps, > > Adam > > > On 25/02/15 10:55, Jan Bracker wrote: > > Hello, > > > > I am trying to use the new type checker plugins [1] that are implemented > > in head. > > > > When successful a plugin has to return a [(EvTerm, Ct)] for the solved > > constraints. The documentation on EvTerms is scarce [2,3,4] and I could > > not find papers that explain them (many talk about 'evidence', but they > > never get concrete). > > > > So far I have figured out that "EvDFunApp DFunId [Type] [EvTerm]" > > selects a certain instance to be used for a constraint, though I don't > > know what the list of EvTerms in the end is for. I am also a bit unclear > > on how the "[Type]" is used.If I turn on '-dcore-lint' I get errors. So > > I still seem to be using it wrong. > > > > I have also asked in IRC, but did not get a response to my question. > > > > I am sorry if this is the wrong mailing list to ask. If there is a more > > apropriate place just point it out. > > > > Best, > > Jan > > > > [1]: https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker > > [2]: > http://haskell.inf.elte.hu/docs/7.11.20150225.noWin32/html/libraries/ghc-7.… > > [3]: > http://haskell.inf.elte.hu/docs/7.11.20150225.noWin32/html/libraries/ghc-7.… > > [4]: > http://haskell.inf.elte.hu/docs/7.11.20150225.noWin32/html/users_guide/comp… > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ >

3 3

Allowing rules to depend upon SimplCont
by Ben Gamari 02 Mar '15

02 Mar '15

In Bug #9661, Comment #12 Simon Peyton-Jones wrote [1], > Annoyingly, the `CoreSyn.RuleFun` API for built-in rules does not give > access to the context of an application (the `SimplCont`), but it > would not be hard to make it do so. > > So if that is the right rewrite, then it'd be another useful project > for someone. I started taking a look at this over the weekend, hoping for a weekend-ish project. Unfortunately it's not as easy as it initially looked. The current state of my work can be found here [2]. The core of the change (as I understand it) is to add a `SimplCont` argument to `RuleFun` [3] although things are in actuality a bit more complicated While it was easy to pipe through the `SimplCont` in the simplifier itself (as it was already keeping track of the `SimplCont` context), `ruleCheck` in `Rules.hs` does not know anything about the simplifier or `SimplCont`. Currently `ruleCheck` is quite simple: It traverses the program examining function applications, looking for rules which apply to the applied function and match a user-specified predicate. It then produces a human-readable message in the event that the rule would not fire. Unfortunately, to evaluate whether the rule will fire we actually need to try calling the `RuleFun`, which now requires having a `SimplCont`. As far as I can tell there are three ways to address this, 1. Pass a dummy `SimplCont` (probably a `Stop`) to the `RuleFun`. This is by far the easiest option but will result in discrepancies between the rule check and the rules actually fired by simplifier. 2. Replicate the simplifier's logic to produce a `SimplCont` in the rule check. This seems like it will result in a great deal of unnecessary (and non-trivial) code duplication. 3. Fold the rule check into the simplifier. It seems like this folds what is currently quite simple code into the already rather complex simplifier. I'm not entirely sure which of these is the least-evil option. Thoughts? Cheers, - Ben P.S. There is also the matter of cyclic module imports. To address these I've split up `SimplUtils.hs` into `SimplCont.hs` and `SimplInline.hs`. Given these two have no cross-dependencies this seems like a reasonable split even independent of the `RuleFun` rework. `Rules.hs` can then import `SimplCont.hs` (although it needs an hs-boot file to satisfy references in `LoadIface.hs`, `HscTypes.hs`, `MkId.hs`). I'll probably reevaluate the need for hs-boot files later. If anyone sees a better restructuring let me know. [1] https://ghc.haskell.org/trac/ghc/ticket/9661#comment:12 [2] https://github.com/ghc/ghc/compare/ghc-7.10...bgamari:wip/rule-context [3] https://github.com/ghc/ghc/commit/a978a4766ebf692820c3b491522b2dd6c642005f [4] https://github.com/bgamari/ghc/blob/c71fb84b8c9ec9c1e279df8c75ceb8a537801aa…

2 4

GHC with cabal-install
by Kazu Yamamoto 27 Feb '15

27 Feb '15

Hello, To my experience, it is easy to install GHC to Linux such as CentOS. But it is hard to install cabal-install after that. Are there any reasons to not include cabal-install in GHC binary packages? GHC provides Cabal library. Why not cabal-install? --Kazu

3 5