- ghc-devs - Haskell.org

Generalising the demand analysis to sum types
by José Manuel Calderón Trilla 04 Mar '16

04 Mar '16

Hello ghc-devs, Apologies for the longish email. I'm looking to generalise GHC's demand analysis to work on sum types. This is in connection with the work on unboxed sums. The idea is that if the strictness analysis tells us that a sum type is strict in all the fields of all of its constructors, it is safe to unbox that sum automatically. We hope for this to feed into a worker/wrapper like transformation for sum types. I am new to the GHC codebase and wanted to make sure that my plan of attack seemed sensible to you all. GHC's current type representing demand is StrDmd, which is defined as follows: data StrDmd = HyperStrict | SCall StrDmd | SProd [ArgStr] | HeadStr I believe that adding sum types will be as simple as adding a single new constructor for Sums: data StrDmd = HyperStrict | SCall StrDmd | SProd [ArgStr] | SSum [(Tag, StrDmd)] | HeadStr We need the constructor tag so that we can analyze each branch of a case expression independently before combining the results of each branch. Since we only care if all fields are strict for all constructors, we won't actually use the tag information except in the analysis itself. Projection-based strictness analysis on sum types is not new (though sum types + higher-order seems to be). That being said, all previous treatments of the subject that I'm aware of forbid polymorphic recursion. Luckily for us we aren't trying to unbox recursive types, so for now [1] we will not attempt to analyze recursive types, hence no SMu or SRec constructor above. With the analysis accepting sum types we will be able to analyze functions with sum types as parameters, as a trivial example: fromMaybe2 x y = case x of Just v -> v Nothing -> y You would get a demand signature like: Str=Dmdtype <S[("Just", <S,U>), ("Nothing", <>)],U><L,U> Which says that the function is strict in its first argument and that if the value is a 'Just' then its field is used strictly, if the value is a 'Nothing' then there is no further demand (a nullary product). For those with more experience in these matter, does this seem to be a sensible approach? Thanks in advance for any insight, Jose [1]: Those of you who saw my Haskell Symposium talk on implicit parallelism last year might remember that we will need the analysis to work on recursive types in order to automatically generate parallel strategies, but that's for later (I've spoken with Ilya Sergey about working on that).

4 8

RTS's (old?) invariant regarding OS blocking
by Dan Aloni 03 Mar '16

03 Mar '16

Hi, While trying to gain insights into the RTS, I've noticed the following in the Wiki page [1] on the topic of the scheduler: Invariant: a task that holds a capability is not blocked in the operating system. This makes some parts of the system simpler - for example, we can use spin locks that spin indefinitely, because we can ensure that the spin lock is only held by a currently executing CPU, and will therefore be released in a finite (and short) amount of time. Does it still apply to modern day GHC, or was it addressed by [2]? [1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Scheduler#Capabilities [2] https://ghc.haskell.org/trac/ghc/ticket/3553 -- Dan Aloni

2 2

Simple "Hello World" Warp-based web server crashes on Ubuntu x86_64
by Антон Десятов 02 Mar '16

02 Mar '16

Hello dear GHC developers, I have recently experienced what I believe to be a bug either in GHC or in Warp library (if it is indeed in Warp then sorry for posting to wrong mailing list). I've managed to shrink it to a few lines of code and publish on a GitHub. Here is the link: https://github.com/anton-dessiatov/warp-ghc-issue What I wanted to do is to establish network connection in my code and then at some point pass it to Warp for further processing. What I got is that after successfully processing first HTTP request my program consumes 100% CPU and eventually crashes with an error like this: *** Error in `/home/farnsworth/work/warp-ghc-issue/.stack-work/install/x86_64-linux/lts-5.5/7.10.3/bin/warp-ghc-issue': double free or corruption (!prev): 0x00000000016214b0 *** Aborted (core dumped) When compiled with -debug I see another message: repro: internal error: ASSERTION FAILED: file rts/Schedule.h, line 137 (GHC version 7.10.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) I tried to debug it by enabling -dcore-lint and -debug in my ~/.stack/config.yaml and what worries me is that in this case Warp itself doesn't compile (tried with 7.10.2 and 7.10.3) giving core lint failure in Network.Wai.Handler.Warp.HTTP2.Worker. Not sure if it is relevant, but looks suspicious. Could anybody please try building my code on x64 Linux, run it, open localhost:8080 in a web browser and confirm that there is indeed a bug? Regards, Anton.

4 8

Re: GADTs and functional dependencies?
by Iavor Diatchki 01 Mar '16

01 Mar '16

Hello Conal, the implementation of fun-deps in GHC is quite limited, and they don't do what you'd expect with existential types (like in your example), type-signatures, or GADTs. Basically, GHC only uses fun-deps to fill-in types for unification variables, but it won't use them to reason about quantified variables. Here is an example that shows the problem, just using type signatures: > class F a b | a -> b where > f :: a -> b -> () > > instance F Bool Char where > f _ _ = () > > test :: F Bool a => a -> Char > test a = a GHC rejects the declaration for `test` because there it needs to prove that `a ~ Char`. Using the theory of fun-deps, the equality follows because from the fun-dep we know that: forall x y z. (F x y, F x z) => (y ~ z) Now, if we instantiate this axiom with `Bool`, `Char`, and `a`, we can prove that `Char ~ a` by combining the instance and the local assumption from the signature. Unfortunately, this is exactly the kind of reasoning GHC does not do. I am not 100% sure on why not, but at present GHC will basically do all the work to ensure that the fun-dep axiom for each class is valid (that's all the checking that instances are consistent with their fun-deps), but then it won't use that invariant when solving equalities. I hope this helps! -Iavor On Tue, Mar 1, 2016 at 9:38 AM, Conal Elliott <conal(a)conal.net> wrote: > Do GADTs and functional dependencies get along? I'm wondering why the > following code doesn't type-check under GHC 7.10.3 and 8.1.20160224: > > > {-# OPTIONS_GHC -Wall #-} > > {-# LANGUAGE GADTs, KindSignatures, MultiParamTypeClasses, > FunctionalDependencies #-} > > > > module FundepGadt where > > > > class C a b | a -> b > > > > data G :: * -> * where > > -- ... > > GC :: C a b => G b -> G a > > > > instance Eq (G a) where > > -- ... > > GC b == GC b' = b == b' > > Error message: > > FundepGadt.hs:14:25: error: > • Couldn't match type 'b1’ with 'b’ > 'b1’ is a rigid type variable bound by > a pattern with constructor: GC :: forall a b. C a b => G b -> > G a, > in an equation for '==’ > at FundepGadt.hs:14:12 > 'b’ is a rigid type variable bound by > a pattern with constructor: GC :: forall a b. C a b => G b -> > G a, > in an equation for '==’ > at FundepGadt.hs:14:3 > Expected type: G b > Actual type: G b1 > • In the second argument of '(==)’, namely 'b'’ > In the expression: b == b' > In an equation for '==’: (GC b) == (GC b') = b == b' > • Relevant bindings include > b' :: G b1 (bound at FundepGadt.hs:14:15) > b :: G b (bound at FundepGadt.hs:14:6) > > I think the functional dependency does ensure that "b == b" is well-typed. > > In contrast, the following type-family version does type-check: > > > {-# OPTIONS_GHC -Wall #-} > > {-# LANGUAGE GADTs, KindSignatures, TypeFamilies #-} > > > > module TyfamGadt where > > > > class C a where > > type B a > > > > data G :: * -> * where > > -- ... > > GC :: C a => G (B a) -> G a > > > > instance Eq (G a) where > > -- ... > > GC b == GC b' = b == b' > > Thanks, - Conal > > _______________________________________________ > ghc-tickets mailing list > ghc-tickets(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets > >

2 2

Patches/proposals waiting for review
by Thomas Miedema 01 Mar '16

01 Mar '16

Hi Simon, the following issues are waiting for your review: * https://phabricator.haskell.org/D1762 "Fix #11348 handle instance dependencies" by Alexander Vieth * https://phabricator.haskell.org/D1896 "Improve printing of pattern synonym types" by Rik Steenkamp * https://ghc.haskell.org/trac/ghc/wiki/ShorterImportSyntax by Anthony Cowley Maybe others, they should show up under "Blocking Others" when you go to https://phabricator.haskell.org/ Thanks, Thomas

5 4

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