October 2014 - Glasgow-haskell-users

GHC 7.4.2 on Ubuntu Trusty
by Yitzchak Gale 22 Oct '14

22 Oct '14

In order support some older software that we released, we need to get a working GHC 7.4.2 on Ubuntu Trusty. We currently have GHC 7.8.3. The binary tarball for GHC 7.4.2 does not install on Trusty due to multiple incompatibilities. For example, GHC requires GMP 3, but Trusty only provides GMP >= 4. Etc. I tried building GHC 7.4.2. from source on Trusty. But the process won't boot from our currently installed GHC 7.8.3. The oldest GHC binary I can get is GHC 7.6.3, which happens to be still available from the Ubuntu distribution itself (neither the binary tarball nor compiling from source work for GHC 7.6.3 on Trusty either). But booting from GHC 7.6.3 won't work either. How do I get a working GHC 7.4.2 on Trusty? Thanks, Yitz

3 2

GADTs in implementation of Template Haskell
by Richard Eisenberg 21 Oct '14

21 Oct '14

I'm doing a bunch of bug-fixes / improvements to Template Haskell. Two of these are to fix GHC bugs #8100 (add standalone-deriving support) and #9064 (add `default` method type signature support), both of which introduce new constructors for `Dec`. This got me thinking about `Dec` and the fact that different declaration forms are allowable in different contexts. (For example, datatype declarations are allowable only at the top level, and fixity declarations are allowable anywhere except in instance declarations.) How to encode these restrictions? With types, of course! Thus, I redesigned `Dec` to be a GADT. Having done so, I'm not 100% convinced that this is the right thing to do. I would love feedback on my full, concrete proposal available at https://ghc.haskell.org/trac/ghc/wiki/Design/TemplateHaskellGADTs Is this a change for the better or worse? Feel free either to comment on the wiki page or to this email. Thanks! Richard

2 1

Dynamic only GHC
by Jeremy 20 Oct '14

20 Oct '14

I'm trying to build a minimal GHC 7.8.3 on Debian Wheezy with only dynamic libraries (this is for a system where disc space is scarce). I'm using this build.mk: GhcRTSWays = thr GhcLibWays = dyn HADDOCK_DOCS = NO DYNAMIC_BY_DEFAULT = YES GhcDynamic = YES Tried with and without GhcDynamic (asked on beginners how it's different to DYNAMIC_GHC_PROGRAMS but still waiting for an answer). It gets near the end of the build, then fails with: HC [stage 1] ghc/stage2/build/Main.dyn_o HC [stage 1] ghc/stage2/build/tmp/ghc-stage2 /usr/bin/ld: cannot find -lHSrts_thr-ghc7.8.3 collect2: error: ld returned 1 exit status make[1]: *** [ghc/stage2/build/tmp/ghc-stage2] Error 1 make: *** [all] Error 2 If I build with only static libraries, everything seems to work OK.

2 5

GHC 7.8.4: call for tickets, show stoppers, and timelines - oh my!
by Austin Seipp 18 Oct '14

18 Oct '14

Hi *, After some discussion with Simon & Mikolaj today, I'd like to direct you all at this: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8.4 This status page is the basic overview of what we plan on doing for 7.8.4. There are two basic components to this page: - Show stopping bugs. - Everything else, which is "nice to have". Show stoppers are listed at the top of the page, in the first paragraph. Right now, this includes: - #9439 - LLVM mangling too vigorously. - #8819 - Arithmetic failures for unregistered systems - #8690 - SpecConstr blow-up And that's all. But what's all the other stuff? That's "everything else". Aside from these tickets listed here - and any future amendments to it - all other tickets will only be considered nice-to-have. What does that mean? - It's low risk to include. - It clearly fixes the problem - It doesn't take Austin significant amounts of time to merge. For example, "Tickets marked merge with no milestone" are all nice-to-have. Similarly, all the *closed tickets* on this page may be re-opened and merged again[1], since most didn't make it to 7.8.4. Ditto with the remaining categories. OK, so that's the gist. Now I ask of you the following: - If you have a show-stopping bug with GHC 7.8.3, **you really, _positively_ need to file a bug, and get in contact with me ASAP**. Otherwise you'll be waiting for 7.10 most likely. - Again: if you have a show stopper, contact me. Very soon. - If there are bugs you *think* are showstoppers, but we didn't categorize them properly, let me know. Anything we accept as a show-stopper will delay the release of 7.8.4. Anything else can (and possibly will) be left behind. Luckily, almost all of the show stoppers have patches. Only #8819 does not, but I have asked Sergei to look into it for me if he has time today. Finally, I would please ask that users/developers do not include their own personal pet tickets under "show stoppers" without consulting me first, at least. :) If it's just nice to have, you can still pester me, of course, and I'll try to make it happen. I would like to have 7.8.4 out and done with by mid November, before we freeze the new STABLE branch for 7.10.1. That's not a hard deadline; just a timeframe I'd like to hit. Let me know if you have any questions or comments; thanks! [1] A lot of the closed tickets on this page had an improper milestone set, which is why they show up. You can mostly ignore them, I apologize. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 1

Re: Windows build broken in Linker.c
by John Wiegley 17 Oct '14

17 Oct '14

>>>>> Simon Marlow <marlowsd(a)gmail.com> writes: > I was working on a fix yesterday but ran out of time. Frankly this code is a > nightmare, every time I touch it it breaks on some platform - this time I > validated on 64 bit Windows but not 32. Aargh indeed. Before I start breaking this code up into pieces, do we have tests that solely target the linking sub-components, and how would I run them? Perhaps I can setup a fleet of virtual machines to try it out in every combination where we expect the code to compile. John

2 1

Re: Type checker plugins
by Adam Gundry 17 Oct '14

17 Oct '14

Thanks Simon, your branch does make it a lot more feasible to unflatten, so I'll just go ahead and implement that in my plugin for now. Eric, that's fair enough, and I don't have any concrete use cases for non-equality constraints at the moment. I'm just keen to minimize the restrictions placed on plugins, because it is much easier to recompile a plugin than make changes in GHC itself! On that note, I still wonder if it would be better to define TcPluginM as a wrapper around TcS rather than TcM. While in principle TcM should suffice, in practice GHC sometimes uses TcS for things that a plugin might want (I've run into TcSMonad.matchFam, which could easily be implemented in TcM instead). Is there any downside to defining a nice API in TcPluginM but providing an escape hatch to TcS, not just TcM? Thanks, Adam On 16/10/14 16:21, Eric Seidel wrote: > Our branch is actually based on yours Simon, are there any changes in the past week that we should pull in for people who want to experiment? > > Adam, we talked about passing other constraints to the plugins, but didn't have a concrete use-case at the time, so we just kept it as simple as possible. I don't see a reason to hide constraints if, as you say, there are plugins that may want to solve them. > > Eric > > Sent from my iPhone > >> On Oct 16, 2014, at 07:08, Simon Peyton Jones <simonpj(a)microsoft.com> wrote: >> >> This will become easier, I think. look on wip/new-flatten-skoelms-Aug14. I'm now unflattening after solving the flat constraints. >> >> Simon >> >> | -----Original Message----- >> | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- >> | bounces(a)haskell.org] On Behalf Of Adam Gundry >> | Sent: 16 October 2014 11:59 >> | To: Iavor Diatchki >> | Cc: glasgow-haskell-users(a)haskell.org >> | Subject: Re: Type checker plugins >> | >> | Hi Iavor, >> | >> | >> | On 13/10/14 21:34, Iavor Diatchki wrote: >> | > Hello, >> | > >> | > We now have an implementation of type-checker with plugin support. >> | If >> | > you are interested in trying it out: >> | > >> | > - Checkout and build the `wip/tc-plugins` branch of GHC >> | >> | >> | Thanks, this is great! I'd been working on a similar implementation, >> | but yours is much better integrated. I am trying to adapt my units of >> | measure plugin to work with this interface, and work out what else I >> | need in TcPluginM. >> | >> | One problem I've run into is transforming the flattened CFunEqCans >> | into unflattened form (so the flatten-skolems don't get in the way of >> | AG-unification). Do you know if there is an easy way to do this, or do >> | I need to rebuild the tree manually in the plugin? >> | >> | Also, I notice that you are providing only equality constraints to the >> | plugin. Is there any reason we can't make other types of constraint >> | available as well? For example, one might want to introduce a >> | typeclass with a special solution strategy (cf. Coercible, or the Has >> | class in OverloadedRecordFields). >> | >> | >> | Cheers, >> | >> | Adam >> | >> | >> | > - As an example, I've extracted my work on using an SMT solver at >> | > the type level as a separate plugin: >> | > >> | > https://github.com/yav/type-nat-solver >> | > >> | > - To see how to invoke a module that uses a plugin, have a look >> | in >> | > `examples/A.hs`. >> | > (Currently, the plugin assumes that you have `cvc4` installed >> | and >> | > available in the path). >> | > >> | > - Besides this, we don't have much documentation yet. For >> | hackers: >> | > we tried to use `tcPlugin` on >> | > `TcPlugin` in the names of all things plugin related, so you >> | could >> | > grep for this. The basic API >> | > types and functions are defined in `TcRnTypes` and `TcRnMonad`. >> | > >> | > Happy hacking, >> | > -Iavor -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

4 7

optimizing StgPtr allocate (Capability *cap, W_ n)
by Bulat Ziganshin 16 Oct '14

16 Oct '14

Hello Glasgow-haskell-users, i'm looking a the https://github.com/ghc/ghc/blob/23bb90460d7c963ee617d250fa0a33c6ac7bbc53/rt… if i correctly understand, it's speed-critical routine? i think that it may be improved in this way: StgPtr allocate (Capability *cap, W_ n) { bdescr *bd; StgPtr p; TICK_ALLOC_HEAP_NOCTR(WDS(n)); CCS_ALLOC(cap->r.rCCCS,n); /// here starts new improved code: bd = cap->r.rCurrentAlloc; if (bd == NULL || bd->free + n > bd->end) { if (n >= LARGE_OBJECT_THRESHOLD/sizeof(W_)) { .... } if (bd->free + n <= bd->start + BLOCK_SIZE_W) bd->end = min (bd->start + BLOCK_SIZE_W, bd->free + LARGE_OBJECT_THRESHOLD) goto usual_alloc; } .... } /// and here it stops usual_alloc: p = bd->free; bd->free += n; IF_DEBUG(sanity, ASSERT(*((StgWord8*)p) == 0xaa)); return p; } i think it's obvious - we consolidate two if's on the crirical path into the single one plus avoid one ADD by keeping highly-useful bd->end pointer further improvements may include removing bd==NULL check by initializing bd->free=bd->end=NULL and moving entire "if" body into separate slow_allocate() procedure marked "noinline" with allocate() probably marked as forceinline: StgPtr allocate (Capability *cap, W_ n) { bdescr *bd; StgPtr p; TICK_ALLOC_HEAP_NOCTR(WDS(n)); CCS_ALLOC(cap->r.rCCCS,n); bd = cap->r.rCurrentAlloc; if (bd->free + n > bd->end) return slow_allocate(cap,n); p = bd->free; bd->free += n; IF_DEBUG(sanity, ASSERT(*((StgWord8*)p) == 0xaa)); return p; } this change will greatly simplify optimizer's work. according to my experience current C++ compilers are weak on optimizing large functions with complex execution paths and such transformations really improve the generated code -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 1

status of rebindable syntax for arrows
by S. Doaitse Swierstra 15 Oct '14

15 Oct '14

The GHC manual already for quite a number of version states: • Arrow notation (see Section 7.17, “Arrow notation ”) uses whatever arr, (>>>), first, app, (|||) and loop functions are in scope. But unlike the other constructs, the types of these functions must match the Prelude types very closely. Details are in flux; if you want to use this, ask! When using this feature we get the error: "Var/Type length mismatch: [s{tv aVL} [tv]] [] ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): tcTyVarDetails s{tv aVL} [tv] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug" So our question is whether we should really report this as a bug, and/or what we can do about this. Thanks for your help, Doaitse

3 2

The future of the haskell2010/haskell98 packages - AKA Trac #9590
by Austin Seipp 14 Oct '14

14 Oct '14

Hello developers, users, friends, I'd like you all to weigh in on something - a GHC bug report, that has happened as a result of making Applicative a superclass of Monad: https://ghc.haskell.org/trac/ghc/ticket/9590 The very condensed version is this: because haskell2010/haskell98 packages try to be fairly strictly conforming, they do not have modules like Control.Applicative. Unfortunately, due to the way these packages are structured, many things are simply re-exported from base, like `Monad`. But `Applicative` is not, and cannot be imported if you use -XHaskell2010 and the haskell2010 package. The net result here is that haskell98/haskell2010 are hopelessly broken in the current state: it's impossible to define an instance of `Monad`, because you cannot define an instance of `Applicative`, because you can't import it in the first place! This leaves us in quite a pickle. So I ask: Friends, what do you think we should do? I am particularly interested in users/developers of current Haskell2010 packages - not just code that may *be* standard Haskell - code that implies a dependency on it. There was a short discussion between me and Simon Marlow about this in the morning, and again on IRC this morning between me, Duncan, Edward K, and Herbert. Basically, I only see one of two options: - We could make GHC support both: a version of `Monad` without `Applicative`, and one with it. This creates some complication in the desugarer, where GHC takes care of `do` syntax (and thus needs to be aware of `Monad`'s definition and location). But it is, perhaps, quite doable. - We change both packages to export `Applicative` and follow the API changes in `base` accordingly. Note that #1 above is contingent on three things: 1) There is interest in this actually happening, and these separate APIs being supported. If there is not significant interest in maintaining this, it's unclear if we should go for it. 2) It's not overly monstrously complex (I don't think it necessarily will be, but it might be.) 3) You can't like `haskell2010` packages and `base` packages together in the general case, but, AFAIK, this wasn't the case before either. I'd really appreciate your thoughts. This must be sorted out for 7.10 somehow; the current situation is hopelessly busted. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

6 7

Dependencies missing when building ghc.
by Magicloud Magiclouds 14 Oct '14

14 Oct '14

Hi, I am with my new Ubuntu Trusty box. I have installed ghc by apt-get. Then I wanted to build ghc from git to upgrade to 7.8.3. I did following commands. I tried 'make clean', or reget the source. No luck yet. $ git clone --recursive git://git.haskell.org/ghc.git $ ./sync-all -r git://git.haskell.org remote set-url origin $ git checkout ghc-7.8.3-release $ ./sync-all get $ rm -r libraries/time # as prompted by sync-all $ ./sync-all get $ ./boot $ ./configure $ make ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds "inplace/bin/ghc-cabal" check libraries/haskell98 "inplace/bin/ghc-cabal" configure libraries/haskell98 dist-install "" --with-ghc="/home/local/ANT/shida/src/git/ghc/inplace/bin/ghc-stage1" --with-ghc-pkg="/home/local/ANT/shida/src/git/ghc/inplace/bin/ghc-pkg" --disable-library-for-ghci --enable-library-vanilla --enable-library-profiling --enable-shared --configure-option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options=" -fno-stack-protector " --with-gcc="/usr/bin/gcc" --with-ld="/usr/bin/ld" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" --with-ranlib="/usr/bin/ranlib" --with-alex="/usr/bin/alex" --with-happy="/usr/bin/happy" Configuring haskell98-2.0.0.4... ghc-cabal: At least the following dependencies are missing: base ==4.8.* make[1]: *** [libraries/haskell98/dist-install/package-data.mk] Error 1 make: *** [all] Error 2 -- 竹密岂妨流水过山高哪阻野云飞 And for G+, please use magiclouds#gmail.com.

3 4