June 2013 - Glasgow-haskell-users

match_co: needs more cases
by Evan Laforge 07 Nov '13

07 Nov '13

I made some strictifying changes and started getting this msg from ghc: match_co: needs more cases vector-0.10.0.1:Data.Vector.Generic.Mutable.MVector{tc r46} (Sym <(vector-0.10.0.1:Data.Vector.TFCo:R:MutableVector{tc r45})>) <main:Util.TimeVectorStorable.Sample{tc r4e} y{tv a4lK} [tv]> It's not just TimeVectorStorable.Sample (which is indeed stored in Data.Vectors), we also have some mysterious compiler-generated symbols: match_co: needs more cases vector-0.10.0.1:Data.Vector.Generic.Mutable.MVector{tc rQA} (Sym <(vector-0.10.0.1:Data.Vector.TFCo:R:MutableVector{tc rQz})>) <a{tv a6IH} [tv]> I assume this is harmless, but I didn't see any other references to this error on the web or on the ghc trac so maybe it's new?

4 5

Overloaded record fields
by Adam Gundry 18 Jul '13

18 Jul '13

Hi everyone, I am implementing an overloaded record fields extension for GHC as a GSoC project. Thanks to all those who gave their feedback on the original proposal! I've started to document the plan on the GHC wiki: http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Plan If you have any comments on the proposed changes, or anything is unclear about the design, I'd like to hear from you. Thanks, Adam Gundry

19 40

A possible alternative to dot notation for record access
by Judah Jacobson 12 Jul '13

12 Jul '13

Hi all, I had a quick idea about record field syntax as specified in the GSoC project plan: http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Plan . Instead of "f.x" (to access field x of record f), maybe we could write "f{x}" as the record selection. That is, we'd reuse the brace notation which is already in place for record updates. Unlike dot notation, this is unambiguous and doesn't conflict with any existing syntax (AFAIK). It would also generalize to "f{x}{y}{z}" instead of "f.x.y.z". This proposal would add two new forms of expressions: f{x} to access field x of data f ({x}) = \f -> f{x} as a field access section Additionally, it seems like record mutation expressions could also have sections: ({x=2}) = \f -> f{x=2} That actually seems useful by itself, regardless of whether we use dot notation for field access. Best, -Judah

10 10

Re: PSA: GHC can now be built with Clang
by Austin Seipp 01 Jul '13

01 Jul '13

Thanks Manuel! I have an update on this work (I am also CC'ing glasgow-haskell-users, as I forgot last time.) The TL;DR is this: * HEAD will correctly work with Clang 3.4svn on both Linux, and OS X. * I have a small, 6-line patch to Clang to fix the build failure in primitive (Clang was too eager to stringify something.) Once this fix is integrated into Clang (hopefully very soon,) it will be possible to build GHC entirely including all stage2 libraries without any patches. The patch is here: http://llvm.org/bugs/show_bug.cgi?id=16371 - I am hoping this will also make it into XCode 5. * I still have to eliminate some warnings throughout the build, which will require fiddling and a bit of refactoring. The testsuite still probably won't run cleanly on Linux, at least, until this is done I'm afraid (but then again I haven't tried...) As for the infamous ticket #7602, the large performance regression on Mac OS X, I have some numbers finally between my fast-TLS and slow-TLS approach. ./gc_bench.slow-tls 19 500000 5 22 +RTS -H180m -N7 -RTS 395.57s user 173.18s system 138% cpu 6:50.71 total vs ./gc_bench.fast-tls 19 500000 5 22 +RTS -H180m -N7 -RTS 322.98s user 132.37s system 132% cpu 5:44.65 total Now, this probably looks totally awful from a scalability POV. And, well, yeah, it is. But I am almost 100% certain there is something extremely screwy going on with my machine here. I base this on the fact that during gc_bench, kernel_task was eating up about ~600% of my CPU consistently, giving user threads no time to run. I've noticed this with other applications that were totally unrelated too (close tweetbot -> 800% CPU usage,) so I guess it's time to learn DTrace. Or turn it on and off again or something. Ugh. Anyway, if you look at the user times, you get a nice 30% speedup which is about what we expect! On a related note, due to the source code structure at the moment, Linux/Clang hilariously suffers from this same bug. That's because while Clang on Linux supports extremely fast TLS via __thread (like GCC,) it falls back to pthread_getspecific/setspecific. I haven't fixed this yet. It'll happen after I fix #7602 and get it merged in. On my Linux machine, gc_bench also sees a consistent 30% speedup between these two approaches, so I think this is a relatively accurate measurement. Well, as accurate as I can be without running nofib just yet. So if you're just dying to have GHC HEAD built with Clang HEAD on Linux because you've got reasons, you should probably hold on. I also may have a similar, better approach to fixing #7602 that is not entirely as evil and sneaky as crashing the WebKit party. I'll follow up on this soon when I have more info in a separate thread to confer with Simon. With nofib results. I hope. But anyway, 7.8 will be shaping up quite nicely - in particular in the Mac OS X department, I hope. Please feel free to pester me with questions or if you attempt something and it doesn't work. On Tue, Jun 25, 2013 at 7:34 PM, Manuel M T Chakravarty <chak(a)cse.unsw.edu.au> wrote: > Austin, > > Thank you very much for taking care of all these clang issues — that is very helpful! > > Cheers, > Manuel > > Austin Seipp <aseipp(a)pobox.com>: >> Hi all, >> >> As of commit 5dc74f it should now be possible to build a working >> stage1 and stage2 compiler with (an extremely recent) Clang. With some >> caveats. >> >> You can just do: >> >> $ CC=/path/to/clang ./configure --with-gcc=/path/to/clang >> $ make >> >> I have done this work on Linux. I don't expect much difficulty on Mac >> OS X, but it needs testing. Ditto with Windows, although Clang/mingw >> is considered experimental. >> >> The current caveats are: >> >> * The testsuite will probably fail everywhere, because of some >> warnings that happen during the linking phase when you invoke the >> built compiler. So the testsuite runner will probably be unhappy. >> Clang is very noisy about unused options, unlike GCC. That needs to be >> fixed somewhere in DriverPipeline I'd guess, but with some >> refactoring. >> * Some of the stage2 libraries don't build due to a Clang bug. These >> are vector/primitive/dph so far. >> * There is no buildbot or anything to cover it. >> >> You will need a very recent Clang. Due to this bug (preventing >> primitive etc from building,) you'll preferably want to use an SVN >> checkout from about 6 hours ago at latest: >> >> http://llvm.org/bugs/show_bug.cgi?id=16363 >> >> Hilariously, this bug was tripped on primitive's Data.Primitive.Types >> module due to some CPP weirdness. But even with a proper bugfix and no >> segfault, it still fails to correctly parse this same module with the >> same CPP declarations. I'm fairly certain this is another bug in >> Clang, but I might be wrong. I'm trying to isolate it. Unfortunately >> Clang/LLVM 3.3 was just released and it won't see bugfix releases. But >> it will *probably* work if we just get rid of the CPP tomfoolery in >> primitive. I'll be testing it in the next few days to see if we can >> get 3.3 supported. (I'm sort of kicking myself in the head for not >> doing this a week or two ago...) >> >> Anyway, there are some rough edges but it should be in shape for 7.8 I >> hope. It should be especially welcome for Mac users. (I'm also hoping >> modern Macs could even go all-clang-all-the-time if my fix for #7602 >> can go in soon...) >> >> PS. If you use ASSERT, I just fixed a lot of instances of using that >> macro, involving whitespace between the name and arguments (commit >> d8ee2b.) Clang does not forgive you for this. Should I note this >> anywhere for the future in the wiki or something? >> >> -- >> Regards, >> Austin - PGP: 4096R/0x91384671 >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin - PGP: 4096R/0x91384671

5 6

Who uses Travis CI and can help write a cookbook for those guys?
by Ryan Newton 28 Jun '13

28 Jun '13

The Travis folks have decided they want to support Haskell better (multiple compiler versions): https://github.com/travis-ci/travis-ci/issues/882#issuecomment-20165378 (Yay!) They're asking for someone to help them up with setup scripts. They mention their cookbook collection here: https://github.com/travis-ci/travis-cookbooks In that thread above, I pasted our little script that fetches and installs multiple GHC versions, but I have little experiences with cloud technologies & VMs. Can someone jump in and help push this forward? As a community I'm sure it would be great to get a higher percentage of Hackage packages using simple, hosted continuous testing... I'd personally like to replace my Jenkins install if they can get the necessary GHC versions in there. Best, -Ryan

1 0

Repeated variables in type family instances
by Richard Eisenberg 26 Jun '13

26 Jun '13

(Sorry for the re-send - got the wrong subject line last time.) Hello all, It's come to my attention that there is a tiny lurking potential hole in GHC's type safety around type families in the presence of UndecidableInstances. Consider the following: > type family F a b > type instance F x x = Int > type instance F [x] x = Bool > > type family G > type family G = [G] This declarations are all valid in GHC 7.6.3. However, depending on the reduction strategy used, it is possible to reduce `F G G` to either Int or Bool. I haven't been able to get this problem to cause a seg-fault in practice, but I think that's more due to type families' strictness than anything more fundamental. Thus, we need to do something about it. I have written a proposal on the GHC wiki at http://hackage.haskell.org/trac/ghc/wiki/NewAxioms/Nonlinearity It proposes a change to the syntax for branched instances (a new form of type family instance that allows for ordered matching), but as those haven't yet been officially released (only available in HEAD), I'm not too worried about it. There are two changes, though, that break code that compiles in released versions of GHC: --- 1) Type family instances like the two for F, above, would no longer be accepted. In particular, the overlap check for unbranched (regular standalone instances like we've had for years) would now check for overlap if all variables were distinct. (This freshening of variables is called 'linearization'.) Thus, the check for F would look at `F x y` and `F [x] y`, which clearly overlap and would be conflicting. 2) Coincident overlap between unbranched instances would now be prohibited. In the new version of GHC, these uses of coincident overlap would have to be grouped in a branched instance. This would mean that all equations that participate in coincident overlap would have be defined in the same module. Cross-module uses of coincident overlap may be hard to refactor. --- Breaking change #1 is quite necessary, as that's the part that closes the hole in the type system. Breaking change #2 is strongly encouraged by the fix to #1, as the right-hand side of an instance is ill-defined after the left-hand side is linearized. It is conceivable that there is some way to recover coincident overlap on unbranched instances, but it's not obvious at the moment. Note that this proposal does not contain a migration path surrounding coincident overlap. In GHC <= 7.6.x, branched instances don't exist and we have coincident overlap among unbranched instances; and in GHC >= 7.8.x, we will prohibit coincident overlap except within branched instances. We (Simon PJ and I) think that this shouldn't be too big of a problem, but please do shout if it would affect you. Please let me know what you think about this proposal! Thanks, Richard

3 10

Type families causing the compiler to hang on recompilation
by Jeroen Weijers 21 Jun '13

21 Jun '13

Hello, I am having a problem with (re)compiling some code I have. I have two modules A and B. In A I have some classes and instances and B uses this. When I try to compile B (with cabal or ghc --make) the first time everything works. When I now modify B (add a space) B is recompiled but the compiler hangs and doesn't seems to be doing anything. I have tested the problem with GHC (x86_64) 7.6.2. 7.6.3 and HEAD. It seems to be very similar to a problem I had earlier: http://hackage.haskell.org/trac/ghc/ticket/7321 but this time there are no GADTs involved. The code of module A (clutter that doesn't contribute to the problem has been removed): > {-# LANGUAGE FlexibleInstances, UndecidableInstances #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE TypeFamilies, TypeOperators, ScopedTypeVariables #-} > {-# LANGUAGE FlexibleContexts #-} > {-# LANGUAGE DataKinds, PolyKinds #-} > > module A where > > import GHC.Generics > > class QA a where > type QRep a > type QRep a = QRep (GRep (Rep a)) > > instance QA () where > type QRep () = () > > -- Kind-polymorphic proxies; > data Pr (a :: k) = Pr > > class (QA (GRep f)) => CaseOf (f :: * -> *) where > type Alg f r k :: * > type GRep f :: * > > -- Only used for the product structure > class QA (ProdRep f) => CaseOfProd (f :: * -> *) where > type ProdAlg f r :: * > type ProdRep f :: * The code of module B: > module B where > import qualified A Given that the code type checks (and if I do not recompile and make an executable directly it actually works) I think this is a bug that might be similar to the bug mentioned in ticket 7321. Does anybody recognise the problem? Should I create a ticket? Cheers, Jeroen Weijers

2 2

GADTs and pattern matching
by Francesco Mazzoli 19 Jun '13

19 Jun '13

Hi list, I had asked this on haskell-cafe but this looks particularly fishy, so posting here in case it is an issue: {-# LANGUAGE GADTs #-} data Foo v where Foo :: forall v. Foo (Maybe v) -- Works foo1 :: Foo a -> a -> Int foo1 Foo Nothing = undefined foo1 Foo (Just x) = undefined -- This works foo2 :: a -> Foo a -> Int foo2 x Foo = foo2' x foo2' :: Maybe a -> Int foo2' Nothing = undefined foo2' (Just x) = undefined -- This doesn't! foo3 :: a -> Foo a -> Int foo3 Nothing Foo = undefined foo3 (Just x) Foo = undefined So it looks like constraints in pattern matching only propagate forwards. Is this intended? Thanks, Francesco

1 1

ConstraintKinds feature suggestion and question about type family peculiarity
by Merijn Verstraaten 17 Jun '13

17 Jun '13

Hello fellow haskellers! I was experimenting with restricting functions operating on GADTs with phantom types to only work on a subset of the possible phantom types. I ended up with the following code: {-# LANGUAGE ConstraintKinds, DataKinds, GADTs, TypeFamilies, TypeOperators #-} import GHC.Prim (Constraint) data Foo a where Foo :: Foo Int Bar :: Foo Char Baz :: Foo Bool type family Restrict a (as :: [*]) :: Constraint type instance where Restrict a (a ': as) = () Restrict x (a ': as) = Restrict x as foo :: Restrict a '[Char, Bool] => Foo a -> Bool foo Bar = True foo Baz = False This seems to works marvellously, but in writing it I ran into 2 annoyances. 1) The type errors produced by trying to use a function on a disallowed phantom type are rather unclear. "Could not deduce (Restrict Int ('[] *)) arising from a use of ‛foo" Which got me thinking, it would be really nice to have a vacuous Constraint that takes an error string as argument, i.e. a constraint that never holds and returns it's error string as type error. This would let you produce far nicer type errors when (ab)using ConstraintKinds and TypeFamilies by, for example, adding an extra Restrict instance "Restrict x '[] = Vacuous "Applying restricted function to disallowed type"" (or something to that effect), producing that message as error rather than the "Could not deduce (Restrict Int ('[] *)" which is a rather unhelpful error if you're not the person that wrote this code and are just using a function with such a Restrict constraint. 2) for some reason the type families syntax always requires a full argument list, which I find rather ugly. I would much prefer to use KindSignatures and write "type family Restrict :: * -> [*] -> Constraint", but GHC does not allow this. Is there a specific reason for not allowing this syntax? Cheers, Merijn Verstraaten

3 2

Cross-compiling GHC: ghc-cabal: /tmp/30869.o: does not exist
by Nikita Karetnikov 14 Jun '13

14 Jun '13

I'm trying to cross-compile GHC 7.6.3; 'make' fails with the mentioned error. How can I debug this issue? I used Guix [1] to build a cross-compiler and related packages: # ./pre-inst-env guix build -K gcc-cross-mips64el-linux-gnu After that I downloaded GHC 7.6.3: # wget http://www.haskell.org/ghc/dist/7.6.3/ghc-7.6.3-src.tar.bz2 Unpacked it: # tar xf ghc-7.6.3-src.tar.bz2 # cd ghc-7.6.3/mk # cp build.mk.sample build.mk Uncommented 'BuildFlavour = unreg' and added 'INTEGER_LIBRARY = integer-simple'. # cd .. # export CROSS_LIBRARY_PATH=/nix/store/qkzhg178l4b3fpnj7ival0h6c1mfgi0l-glibc-cross-mips64el-linux-gnu-2.17/lib # export CROSS_CPATH=/nix/store/qkzhg178l4b3fpnj7ival0h6c1mfgi0l-glibc-cross-mips64el-linux-gnu-2.17/include:/nix/store/g4ky5zb70y946pfjiq45sa5pv7qdqgha-linux-libre-headers-cross-mips64el-linux-gnu-3.3.8/include # ./configure \ --target=mips64el-linux-gnu \ --with-gcc=/nix/store/lv3vxm43mmk7f5gc1myzs0aj8pi4a4g7-gcc-cross-mips64el-linux-gnu-4.7.3/bin/mips64el-linux-gnu-gcc \ --with-ld=/nix/store/jys3nw5rg2a4lrihs7qhflxad4bwyry6-binutils-cross-mips64el-linux-gnu-2.23.2/bin/mips64el-linux-gnu-ld \ --with-nm=/nix/store/jys3nw5rg2a4lrihs7qhflxad4bwyry6-binutils-cross-mips64el-linux-gnu-2.23.2/bin/mips64el-linux-gnu-nm # make [...] CROSS_COMPILE="mips64el-unknown-linux-gnu-" "inplace/bin/ghc-cabal" configure --with-ghc="/home/GHC/ghc-7.6.3/inplace/bin/ghc-stage1" --with-ghc-pkg="/home/GHC/ghc-7.6.3/inplace/bin/ghc-pkg" --flag=include-ghc-prim --disable-library-for-ghci --configure-option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" -Wl,--hash-size=31 -Wl,--reduce-memory-overheads " --configure-option=CPPFLAGS=" " --with-gcc="/nix/store/lv3vxm43mmk7f5gc1myzs0aj8pi4a4g7-gcc-cross-mips64el-linux-gnu-4.7.3/bin/mips64el-linux-gnu-gcc" --configure-option=--with-cc="/nix/store/lv3vxm43mmk7f5gc1myzs0aj8pi4a4g7-gcc-cross-mips64el-linux-gnu-4.7.3/bin/mips64el-linux-gnu-gcc" --with-ar="/usr/bin/ar" --with-ranlib="true" --with-alex="/usr/bin/alex" --with-happy="/usr/bin/happy" -- dist-install libraries/ghc-prim Configuring ghc-prim-0.3.0.0... ghc-cabal: /tmp/30869.o: does not exist make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error 1 make: *** [all] Error 2 Then I found this bug report [2] and decided to apply the mentioned patch: # cd .. # git clone https://github.com/ghc/ghc.git ghc-github # cd ghc-github # git show f77291d60f33fe601dbe0ff94b0192c5cd4ad6b5 > ld.patch # cd ../ghc-7.6.3 # patch -p1 < ../ghc-github/ld.patch patching file rules/build-package-data.mk Hunk #1 succeeded at 64 (offset -11 lines). # make distclean # ./configure [...] # make Then another error appeared: CROSS_COMPILE="" "inplace/bin/ghc-cabal" configure --with-ghc="/usr/local/bin/ghc" --with-ghc-pkg="/usr/local/bin/ghc-pkg" --package-db=/home/GHC/ghc-7.6.3/libraries/bootstrapping.conf --disable-library-for-ghci --configure-option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" -Wl,--hash-size=31 -Wl,--reduce-memory-overheads " --configure-option=CPPFLAGS=" " --constraint "Cabal == 1.16.0" --constraint "hpc == 0.6.0.0" --constraint "binary == 0.5.1.1" --constraint "bin-package-db == 0.0.0.0" --constraint "hoopl == 3.9.0.0" --with-gcc="/usr/bin/gcc" --with-ld="/nix/store/jys3nw5rg2a4lrihs7qhflxad4bwyry6-binutils-cross-mips64el-linux-gnu-2.23.2/bin/mips64el-linux-gnu-ld" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" --with-ranlib="true" --with-alex="/usr/bin/alex" --with-happy="/usr/bin/happy" -- dist-boot libraries/Cabal/Cabal Configuring Cabal-1.16.0... ghc-cabal: /tmp/27862.o: does not exist make[1]: *** [libraries/Cabal/Cabal/dist-boot/package-data.mk] Error 1 make: *** [all] Error 2 I can't find any similar reports. Am I on the right track? [1] https://gnu.org/software/guix/ [2] http://hackage.haskell.org/trac/ghc/ticket/6086

1 0