- ghc-devs - Haskell.org

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

Build failures with -DDEBUG
by Thomas Miedema 18 Feb '16

18 Feb '16

Simon, the commits you pushed today don't validate with -DDEBUG. Unexpected failures: patsyn/should_compile MoreEx [exit code non-0] (normal) patsyn/should_compile T11224b [exit code non-0] (normal) polykinds MonoidsTF [exit code non-0] (normal) polykinds T11480b [exit code non-0] (normal) polykinds T11523 [exit code non-0] (normal) typecheck/should_fail TcCoercibleFail [stderr mismatch] (normal) TcCoercibleFail timed out, and the others all hit the following debug assert: =====> T11224b(normal) 2510 of 5029 [0, 0, 0] Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160218 for x86_64-unknown-linux): ASSERT failed! CallStack (from HasCallStack): assertPprPanic, called at compiler/types/TyCoRep.hs:1932:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:1991:17 in ghc:TyCoRep substTys, called at compiler/types/TyCoRep.hs:2012:14 in ghc:TyCoRep substTheta, called at compiler/typecheck/TcPatSyn.hs:255:20 in ghc:TcPatSyn in_scope InScope {d_ap0 c_apv} tenv [ap1 :-> c_apv[tau:5]] tenvFVs [aps :-> t_aps[tau:1], apv :-> c_apv[tau:5]] cenv [] cenvFVs [] tys [] cos [] Complete log from Travis: https://s3.amazonaws.com/archive.travis-ci.org/jobs/110115377/log.txt -- Thomas

2 1

Re: Fwd: Is anything being done to remedy the soul crushing compile times of GHC?
by Andrey Mokhov 18 Feb '16

18 Feb '16

Thomas Tuegel <ttuegel(a)gmail.com> writes: > > What exactly does the pre-process phase do, anyways? > It runs the appropriate pre-processor (Alex, Happy, c2hs, etc.) for modules > that require it. It's slow because of the way the process is carried out: For > each module in the package description, Cabal tries to find an associated .hs > source file in the hs-source-dirs. If it cannot, it looks for a file with an > extension matching one of the pre-processors it knows about. If it finds one, > it runs the corresponding program if the output files are missing or outdated. Interesting! In the new Shake-based build system we also need to automagically generate .hs files using Alex et al. My first implementation was slow but then I realised that it is possible to scan the source tree only once and remember where all .hs/.x/etc files are. This brought down the complexity from quadratic to linear in my case -- maybe this could be reused in cabal too? By the way, there seem to be a fair amount of code & functionality overlap in cabal and the new build system. We might want to look into this once the build system becomes more stable. Cheers, Andrey

3 3