- ghc-devs - Haskell.org

GHC 8.0.1 status
by Ben Gamari 01 Mar '16

01 Mar '16

tl;dr. Stabilizing the ghc-8.0 is taking a bit longer than was anticipated. The release schedule is being pushed back a bit. Hello everyone, As you likely know we are currently in the depths of the 8.0 release. In fact, under more ideal circumstances I would probably be cutting another release candidate right now instead of writing this email, in preparation for a final release next week or so. However, our world is far from ideal as evidenced by the number [1] of significant bugs present on the 8.0 branch. This isn't altogether unexpected; we knew we were taking a bit of a risk in merging so many high-impact patches in one release. However, we thought that given a longer-than-usual period between first-candidate and the final release, we'd have enough time to smooth out the wrinkles. Sadly, this has taken a bit longer than we anticipated. Of course, the last thing we want is to push a known buggy release out the door. Consequently, we won't be delivering the 8.0.1 release next week as originally planned. Instead, we'll be pushing the release back by about three weeks. This will give developers a bit more breathing room in which to work out the remaining issues. Hopefully in a few weeks the tree will be in such a state that we can push out yet another candidate which, with luck, will be the last before the release. If you'd like to expedite the process (and have fun in the process), you could do worse than to having a look at Trac [1], choosing a bug of your liking, and trying your hand at solving it. Thanks to everyone who has contributed to this effort thusfar. If you have any questions about the release process or how you can help, don't hesistate to ask. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1

3 4

Change in demand analysis results between 7.10.2 and RC1 (not fixed in RC2 and HEAD)
by Ömer Sinan Ağacan 29 Feb '16

29 Feb '16

Hi all, While working on demand analyzer today we realized that there has been some changes in demand analysis results between GHC 7.10.2 and 8.0-rc2. Here's a minimal example: {-# LANGUAGE BangPatterns #-} module Main where data Prod a = Prod !a !a addProd :: Prod Int -> Prod Int -> Prod Int addProd (Prod i1 i2) (Prod i3 i4) = Prod i1 (i2 + i4) main = return () Compiled with 7.10.2: addProd :: Prod Int -> Prod Int -> Prod Int [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType <S(SS),1*U(U,U(U))><S(SS),1*U(1*H,U(U))>m, ...}}}}] addProd = \ (ds_dzH :: Prod Int) (ds1_dzI :: Prod Int) -> case ds_dzH of _ [Occ=Dead] { Prod i1_an2 i2_an3 -> case i2_an3 of _ [Occ=Dead] { GHC.Types.I# x_s2B4 -> case ds1_dzI of _ [Occ=Dead] { Prod i3_an4 i4_an5 -> case i4_an5 of _ [Occ=Dead] { GHC.Types.I# y_s2B7 -> Main.Prod @ Int i1_an2 (GHC.Types.I# (GHC.Prim.+# x_s2B4 y_s2B7)) } } } } Compiled with 8.0-rc2: -- RHS size: {terms: 20, types: 17, coercions: 0} addProd :: Prod Int -> Prod Int -> Prod Int [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType <S(SS),1*U(U,U(U))><S(LS),1*U(A,U(U))>m, ...}}}}] addProd = \ (ds_dQL :: Prod Int) (ds1_dQM :: Prod Int) -> case ds_dQL of _ [Occ=Dead] { Prod i1_avS i2_avT -> case i2_avT of _ [Occ=Dead] { GHC.Types.I# x_s1vO -> case ds1_dQM of _ [Occ=Dead] { Prod i3_avU i4_avV -> case i4_avV of _ [Occ=Dead] { GHC.Types.I# y_s1vR -> Main.Prod @ Int i1_avS (GHC.Types.I# (GHC.Prim.+# x_s1vO y_s1vR)) } } } } To highlight the difference, GHC 7.10.2: <S(SS),1*U(U,U(U))><S(SS),1*U(1*H,U(U))> GHC 8.0-rc2: <S(SS),1*U(U,U(U))><S(LS),1*U(A,U(U))> (NOTE: Also tried with HEAD and rc1 just now, the results are the same as rc2) The demand put on the second argument is more strict in GHC 7.10. Was that an intentional change? Any ideas on why this might be happening? In our case, we prefer the result in 7.10.2 of course, because that's a more precise demand and it gives us more opportunities for optimizations. But I guess this could potentially reveal itself in some other situations and make some programs slower? Any ideas? Thanks..

3 4

CoreLint check for case with no alts
by Ömer Sinan Ağacan 29 Feb '16

29 Feb '16

Hi all, CoreLint has a check that, when seeing a case expression with empty list of alternatives, checks whether the scrutinee is bottom. This "bottom-ness" check is, however, very simple and returning many false negatives. For example, when it sees a case expression, all it does is: go _ (Case _ _ _ alts) = null alts Which is just too simple for some cases. (it could check if all the RHSs are bottom, or if the scrutinee is bottom etc.) I guess this makes sense, since it's OK to generate unreachable code, but it's not OK to not generate a code in a reachable path. But in my case this is becoming problem as it's rejecting my seemingly valid program. One of the relevant parts in my code is this: case ww_s4C3 of ww_X4Fb { (#_||#) ww_s4Ce -> case case ww_s4Ce of ww_s4F1 { (# ww_s4F2, ww_s4F3 #) -> lvl_s4F4 ww_s4F3 ww_s4F2 } of wild_00 { -- empty }; lvl_s4F4 :: Int# -> String -> Var [LclId, Arity=2, Str=DmdType (args: <L,U><L,U>) (res: x)] lvl_s4F4 = \ (ww_s4F3 :: Int#) (ww_s4F2 :: String) -> lvl_s3V4 (TyVar ww_s4F2 ww_s4F3) lvl_s3V4 :: Var -> Var [LclId, Arity=1, CallArity=1, Str=DmdType (args: <B,1*H>) (res: x)] lvl_s3V4 = \ (i_a1vO :: Var) -> lvl_s4EZ i_a1vO lvl_s4EZ :: Var -> Var [LclId, Arity=1, Str=DmdType (args: <L,U>) (res: x)] lvl_s4EZ = \ (i_a1vO :: Var) -> error ... The scrutinee part of the case expression in the alternative is clearly bottom, but this expression is rejected by the linter. One easy solution is to implement a more precise test and use it in linter. But I thought maybe the current implementation is deliberately so. Maybe the code generator doesn't support that type of code etc. so I wanted to ask: Is there a restriction on what kind empty case expressions are supported by the code generator or can I just improve the lint check and assume that the code will be handled by the code generator correctly? Thanks.

2 3

[ANNOUNCE] GHC 8.0.1 release candidate 2
by Ben Gamari 29 Feb '16

29 Feb '16

Hello everyone, The GHC Team is very pleased to announce the second release candidate of the Glasgow Haskell Compiler 8.0.1 release. Source and binary distributions as well as the newly revised users guide and Haddock documentation can be found at http://downloads.haskell.org/~ghc/8.0.1-rc2/ This is the second in a series of release candidates leading up to the 8.0.1 release and fixes many of the issues reported in -rc1. These fixes include, * A re-rewrite of the pattern checker by George Karachalias. The new checker should have far more predictable performance characteristics while sacrificing minimal reasoning power. This should resolve a large number of the issues felt in -rc1. * Richard Eisenberg has been hammering out all manner of type-application- and TypeInType-related issues (#11335, #11416, #11405). There is still more work to do here, however (e.g. #11471). * Matthew Pickering has restored support for multi-clause pattern synonyms (#11367) * A latent bug in the constraint solver which popped up as a build failure in xmonad-contrib in -rc1 has been fixed (#11379) * Dimitrios Vytiniotis and Simon Peyton Jones has been squashing a variety of older type-checker bugs at a furious rate (#11458, #11248, #11330, #11408) * Simon Peyton Jones has taught demand analysis to more precisely handle exceptions (#11222) * Tamar Christina has added support for remote GHCi on Windows and resolved a long-standing linking issue (#11223) * Loading of compiled modules needing shared library symbols now works in GHCi thanks to Peter Trommler (#10458) * A variety of limitations in our implementation of Typeable implementation have been fixed (#11120) although there is still more to be done (#11334). * A terrible failure of type inference due to visible type application has been fixed (#11458) * InjectiveTypeFamilies has been renamed to TypeFamilyDependencies * Custom type errors are now more robust (#11391) although there is still more work to be done (#11541) * We now have a more conservative default warning set, as well as better mechanisms for managing warning changes in the future. (#11429, #11370) * Compatibility with earlier Cabal versions should be a bit more robust. * The user-facing interface of the (formerly "implicit") CallStack functionality has been reworked, hiding the implicit callstack parameter behind a constraint synonym. * Online haddock documentation has been restored (#11419) * We now offer xz archives exclusively * A variety of miscellaneous bug-fixes have also been merged. All of these changes add up to nearly 200 commits in total. Given the large amount of churn between this candidate and -rc1, as well as the fact that there is at least one more significant patch pending (D1891, to fix #11471 and others), we will be releasing a third release candidate in a few weeks which should address more of the issues listed on the release status page [1]. Assuming things go well, we should be able to cut a final release by early March at the latest. All of the builds above were produced from the ghc-8.0.1-rc2 tag (commit e2230228906a1c0fa1f86a0c1aa18d87de3cc49d) *with the exception of the Windows builds*. Unfortunately, it was realized only too late that the tagged commit is broken on Windows. Consequently, the Windows builds were produced from the ghc-8.0.1-rc2 tag with two additional patches (commit 5b35c5509adb1311856faa0bc9767aec9ad5e9b7). While this would of course be completely unacceptable for a proper release, time constraints have meant that this was unfortunately the only viable option for this release candidate. We apologize for any confusion this may cause. At this point we are working very hard to nail the remaining bugs labelled as "highest" priority on the 8.0.1 status page [1]. If you have an issue which you'd like to see addressed in the release that does not appear in this list, please bring it to our attention. As always, we look forward to hearing about any issues that you encounter with this candidate. Thanks to everyone who has contributed so far! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1

12 28

Pattern synonym thoughts
by David Feuer 25 Feb '16

25 Feb '16

There are two features I think would make pattern synonyms even nicer: 1. If a pattern synonym is defined in the same module as one of the type constructors in the type of thing it matches, then it should be possible to export it "attached" to one or more of those constructors (normally but not necessarily the outermost one g. An example of how this might look: module Foo (A (.., S)) data A = X | Y pattern S = X Someone writing a module importing Foo wouldn't even need to know that S was a pattern synonym--they'd just import Foo (A (..)) and be done with it. The (.., S) here means "export all A's constructors, along with the pattern synonym S". 2. Pattern synonym groups This vague idea attacks a long-standing efficiency concern. It's not fully formed in my mind, but I'd love to be able to write groups of pattern synonyms that all use a *guaranteed shared* computed view of the underlying structure. Once the first synonym in the group is encountered, the view is calculated and held until the pattern match completes or the last synonym in the group is rejected.

2 1

ORF and renamer
by Alan & Kim Zimmerman 23 Feb '16

23 Feb '16

I am working on updating HaRe for GHC 8.0.1, and have hit an issue with the following file --------------------------- module Field1 where --Rename field name 'pointx' to 'pointx1' data Point = Pt {pointx, pointy :: Float} absPoint :: Point -> Float absPoint p = sqrt (pointx p * pointx p + pointy p * pointy p) -------------------------- It seems that after the renamer, each of the three instances of `pointx` has a different `nameUnique` value. Is this because the final resolution is now done during type checking? If so it makes the RenamedSource much harder to work with. Alan

2 3

"Excuse me, I think this i my stop..." - Resigning from the Platform
by Mark Lentczner 22 Feb '16

22 Feb '16

I think this is the right time for me to exit: The truth is, I still can't bring myself to use a version of Haskell post the Foldable-Traversable-aPocalypse, let alone some future Haskell after the changes now in the works. My personal machines are all still 7.8. My personal projects are all pre-FTP. The Haskell I love to code in, the Haskell I'm passionate about, the Haskell I've advocated for real world use, and the Haskell I like to teach, is 7.8, pre-FTP. It's not that I'm dead set against change and evolution in a language, or even breaking changes. But FTP and beyond are changes that have lost the balance that Haskell had between abstraction and clarity, between elaborate and practical engineering. I don't see any restraint going forward, so I'm getting off the train. This puts me in an odd position with respect to Haskell Platform: I find myself building the Platform for a version of Haskell that I don't use. This isn't healthy for either the Platform or me. Hence, I'm resigning as release manager. I am sad because I believed that Haskell's path to much wider adoption was within reach. Now, especially with the ramping up of the Haskell Prime committee, which seems preordained to codify FTP and beyond into standard, we are approaching our Algol 68 moment: Building a major language revision with less opportunity than it's predecessor. I'll still see you 'round at meet-ups and conferences. I'll just be coding with an older accent. - Mark "mzero" Lentczner

7 8

Fwd: Compiling Core Haskell using GHC API
by Marek Wawrzos 20 Feb '16

20 Feb '16

Hello, I'm trying to compile some module with GHC API. I'm going to feed GHC with Core generated by me. So far is noticed, that function compileCoreToObj ends with an runtime error on each call. In spide of this function produces some *.o and *.hi files. However, produced interface file does not contain any item in exports field, what makes compiled module unusable. Because of this problem, I tried to achieve my goal by using steps described here: https://wiki.haskell.org/GHC/As_a_library (the second example) I was able to print out Core produced form file. If I'm not wrong, modifying structures passing on between sequent calls does not effect on produced *.hi and *.o files. Both files are generated by `load LoadAllTargets' call, and further calls (parseModule, loadModule, ...) does not effect on generated files. Could You give me any advices in that topic? Am I right about compileCoreToObj and functions mentioned above? Best Regards, Marek

2 3

Advice for #11475
by Jonas Scholl 19 Feb '16

19 Feb '16

Hello GHC-Devs, I am currently giving #11475 a try. However I hit a few problems and wanted to ask for a bit of advice about how to proceed. I already can handle the following: case x of A y -> e1 _ -> ....(case x of B -> r2 C -> r3) ... My first problem then was the following construct: case (case ... of ... -> Left x) of Left y -> ... Or more simple: case Left x of Left y -> ... So I have to check which constructors the scrutinee may return. I know the simplifier has to implement such logic somewhere but did not want to use the implementation for two reasons: - I didn't know where to find it - If GHC uses the same test to prune impossible alternatives and to check if they were pruned correctly, extending the linter is useless. A bug in the test code will cause also cause a bug in the linter. So I implemented such a test myself, but now I am stuck at something like this: foo a b = a : b bar = ... case foo a b of (:) x y -> ... I cannot see through foo, so I assume it may return (:) and []. The simplifier on the other hand is able to see through foo and did remove the [] case, causing my current implementation to throw an incorrect lint error. How can I get a list/set of all possible AltCons returned by a function/constant? Or a list of the impossible ones? I tried to get some information from the unfolding of a variable, but it seems like unfoldings are only attached to top-level names. Jonas

2 1

Missing definitions of associated types
by David Feuer 18 Feb '16

18 Feb '16

It seems to be that a missing associated type definition should be an error, by default, rather than a warning. The current behavior under those circumstances strikes me as very strange, particularly for data families and particularly in the presence of overlapping. {-# LANGUAGE TypeFamilies #-} class Foo a where data Assoc a foo :: proxy a -> Assoc a instance {-# OVERLAPPABLE #-} Foo a where data Assoc a = AssocGeneral foo _ = AssocGeneral instance {-# OVERLAPS #-} Foo Char where foo _ = AssocGeneral blah :: Assoc Char blah = foo (Proxy :: Proxy Char) This compiles with just a warning because Assoc Char *falls through* to the general case. WAT? This breaks all my intuition about what associated types are supposed to be about.

2 2