- ghc-devs - Haskell.org

Impredicative types and forall regression in 8.0 ?
by Vincent Hanquez 16 Feb '16

16 Feb '16

Hi GHC-Devs, I recently came across a compilation problem on 8.0 that do not trigger on < 8.0. I've reduced the issue to this snippet with Rank2Types: type Action = (forall a . Show a => a) -> Int data Command = Command (Maybe Action) com1 = Command Nothing With GHC 7.0 to 7.10, this compile and works. However on GHC 8.0, I now have: Test.hs:19:16: error: • Cannot instantiate unification variable ‘a0’ with a type involving foralls: Action GHC doesn't yet support impredicative polymorphism • In the first argument of ‘Command’, namely ‘Nothing’ In the expression: Command Nothing In an equation for ‘com1’: com1 = Command Nothing I workarounded it by "inlining" the maybe and creating a proper wrapping type: data Action2 = Action2 ((forall a . Show a => a) -> Int) | NoAction2 data Command2 = Command2 Action2 com2 = Command2 NoAction2 Any idea why this is triggering this issue in GHC 8.0 ? Is this something that need fixing maybe ? Cheers, -- Vincent

3 3

quick performance measurements
by Richard Eisenberg 15 Feb '16

15 Feb '16

Hi devs, I have a few ideas for tweaks to improve compiler performance. (For example, reversing the order of comparisons in a short-circuiting comparison operation.) I don't have a particular test case with a profile that tells me where the smoking gun is. But I'd like to try these easy tweaks just to see if performance improves. My question: Is there an easy way to run some command that will give me helpful feedback on my performance tweak? Of course, I could push to a branch and have perf.haskell.org tell me. But that takes a long time. I could compile a few files and examine the output manually. But that's a bit painful. Ideally, there would be a way to run a portion of the testsuite and have the testsuite tool aggregate performance characteristics and report. Or perhaps there's a way to get cabal to aggregate performance characteristics, and I could just try compiling a few libraries. Any ideas out there? Thanks! Richard

5 6

New type of expressions containing (error ...) includes noisy implicit parameter
by Christopher Allen 15 Feb '16

15 Feb '16

Prelude> let myList = [1, 2, 3 :: Integer] Prelude> let myList' = myList ++ undefined Prelude> :t myList myList :: [Integer] Prelude> :t myList' myList' :: (?callStack::GHC.Stack.Types.CallStack) => [Integer] This is on by default and insofar as I've been able to try, it's avoidable in a default GHCi 8.0 REPL session. I'm glad I caught this before our book goes to print in a couple months. We'd managed to avoid talking about implicit parameters in 1,100+ pages of book but now we're forced to acknowledge their existence in the 4th of 32 chapters. This slipped past the radar more stealthily than the earlier stages of BBP did for 7.10. I was hearing about BBP on the GHC Trac pretty early on for months on end. Was the thinking that people still used implicit parameters for anything or taught them? On the one hand, this is a nice change and something I personally attempted (and failed) to make easier in GHC 7.10. The implementation making the types noisy rankles and didn't seem necessary when I investigated it between 7.8 and 7.10. Could you warn us when (educationally relevant?) stuff like this is coming down the pipe before the RC please? Ideally during the design phase. I think this was discussed as part of FTP to avoid future debacles. This isn't just a pedagogical problem, this is a UX problem. The users don't _care_ that call stack information is being carried around. Why would they? It happens without any mention in the types in almost every other programming language. --- Chris Allen

5 5

[Template Haskell] Desugaring TH brackets vs. Desugaring normal HsExprS.
by Dominik Bollmann 15 Feb '16

15 Feb '16

Hi, I'm currently trying to understand GHC's implementation of Template Haskell and I've had the following two questions when reading upon deSugar/DsMeta.hs and deSugar/dsExpr.hs (disclaimer: I'm a complete newbie to GHC and do not know pretty much anything about its internals; so please excuse silly questions). 1) As far as I understand DsMeta, its purpose is to desugar the contents of TH quotation brackets, e.g. [| \x -> x |]. Given the HsExpr contents, say `expr`, of a quotation bracket, it creates a CoreExpr /representation/ of `expr` such that /evaluating/ this CoreExpr representation yields a TH expression equivalent to `expr`. (This is similar to how quotations are implemented in the original TH paper). On the other hand, when instead writing the above TH quote, (i.e., [| \x -> x |]), explicitly as newName "x" >>= (\x -> lamE (varP x) (varE x)) (*) there is no need to build a CoreExpr /representation/ because we already got the TH value we're interested in; Hence, in this case DsExpr desugars the above (*) directly to a CoreExpr that represents it. Is my understanding of the above correct? I tried to confirm it using the following to splices: test1 :: Q Exp test1 = [| \x -> x |] test2 :: Q Exp test2 = do x <- newName "x" lamE [(varP x)] (varE x) However, dumping the desugared output of these splices using `-ddump-ds` gives the exact same CoreExprS: test1 :: Q Exp [LclIdX, Str=DmdType] test1 = Language.Haskell.TH.Syntax.bindQ @ Name @ Exp (newName (GHC.CString.unpackCString# "x"#)) (\ (x_a399 :: Name) -> lamE (GHC.Types.: @ PatQ (varP x_a399) (GHC.Types.[] @ PatQ)) (varE x_a399)) test2 :: Q Exp [LclIdX, Str=DmdType] test2 = >>= @ Q Language.Haskell.TH.Syntax.$fMonadQ @ Name @ Exp (newName (GHC.CString.unpackCString# "x"#)) (\ (x_a39a :: Name) -> lamE (GHC.Types.: @ PatQ (varP x_a39a) (GHC.Types.[] @ PatQ)) (varE x_a39a)) Could anyone explain to me why both CoreExpr dumps are the same? Shouldn't the first be a /representation/ that, only when run, yields the second CoreExpr? If anyone could help me understanding this, it'd be great! Thanks, Dominik.

2 1

Reconsidering -Wall and -Wcompat
by Ben Gamari 15 Feb '16

15 Feb '16

tl;dr. GHC has a new set of warnings, -Wcompat, intended to give users advance notice of coming library changes. We want to know whether you think this set should be included in -Wall. See the Wiki [4] and voice your opinion via the linked poll. Hello everyone, GHC 8.0.1 will include a new warning group, -Wcompat, which arose out of the MonadFail proposal discussion [1] late last year. This warning set is intended to provide a means of informing users of coming changes in GHC's core libraries. We would like to solicit the community's feedback on whether this new flag set should be implied by -Wall. This proposal is motivated by concern expressed by some that -Wcompat would see little usage unless it is placed in one of the warning sets typically used during development. One such set is -Wall, which enables a generous fraction of GHC's warning collectionand is is intended [2] for use during development. Unfortunately, despite the (albeit only recently stated) intent of flag, -Wall is widely used outside of development [3], often with the expectation that the result be warning-clean across multiple GHC versions. While we hope that -Wall will see less use in this context in the future, given its current role we wouldn't want to add options to it that would cause undue burden for users. So, we are asking for your opinion: should -Wcompat be implied by -Wall? You can find a more thorough description of the precise proposal on the GHC Wiki [4]. It would be very much appreciated if you could take a few minutes familiarize yourself with the options and provide your thoughts via this quick poll, https://docs.google.com/forms/d/1BmIQvhHcnDB79LgBvaWl_xXpS1q0dMHe3Gq9JeU9od… Feel free to discuss the issue further in this thread. Thank you for sharing, - Ben [1] https://mail.haskell.org/pipermail/ghc-devs/2015-October/010101.html [2] https://mail.haskell.org/pipermail/ghc-devs/2016-January/010955.html [3] In a rather unscientific study, nearly half of packages on Hackage include it in ghc-options, $ tar -xf ~/.cabal/packages/00-INDEX.tar $ (for pkg in $(ls); do ls $pkg/*/*.cabal | sort -r | head -n1; done) | xargs grep -L '\-Wall' | wc -l 4352 $ ls | wc -l 9347 [4] https://ghc.haskell.org/trac/ghc/wiki/Design/Warnings/Wcompat

6 9

Potentially confusing syntax for injective type families
by Matthew Pickering 15 Feb '16

15 Feb '16

I was updating haskell-src-exts for ghc 8.0 recently and found some of the syntax for injective type families quite confusing. Is it a problem that the two following snippets have quite different meanings? 1. With the infectivity annotation, this declares an associated type. class Hcl a b where type Ht a b = r | r -> b a 2. Without the infectivity annotation, this declares an associate type synonym default. This isn't valid because Ht is not declared as an associated type before hand and r is not mentioned on the LHS. class Hcl a b where type Ht a b = r Has this been considered? Matt

3 4

GHC build time graphs
by Edward Z. Yang 13 Feb '16

13 Feb '16

Joachim, Anthony Cowley was recently complaining on Twitter that building GHC takes 39.5% longer now than it did for 7.10.1: https://twitter.com/a_cowley/status/692481516744634368 Do we have graphs for these metrics, e.g. can we see the breakdown of which commits increased the build time? Thanks, Edward

6 9

GHC performance dashboard question
by Jan Stolarek 12 Feb '16

12 Feb '16

Joachim, what do I need to do to have my wip/ branch picked up by the performance dashboard? I'm thinking about branch wip/js-hoopl-cleanup, which was pushed yesterday but still hasn't been measured for performance. Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system.

2 1

Validation failures
by Simon Peyton Jones 12 Feb '16

12 Feb '16

I’m getting this on a clean HEAD. Is anyone else? Simon Unexpected stat failures: perf/compiler T5030 [stat not good enough] (normal) perf/compiler T9872b [stat not good enough] (normal) perf/compiler T9872c [stat not good enough] (normal)

2 2

Re: [Haskell-cafe] New type of ($) operator in GHC 8.0 is problematic
by Richard Eisenberg 11 Feb '16

11 Feb '16

Perhaps it will aid the discussion to see that the type of ($) will, for better or worse, be changing again before 8.0. The problem is described in GHC ticket #11471. The details of "why" aren't all that important for this discussion, but the resolution might be. The new (hopefully final!) type of ($) will be: > ($) :: forall (r :: RuntimeRep) (a :: *) (b :: TYPE r). (a -> b) -> a -> b Once again, it's easy enough to tweak the pretty-printer to hide the complexity. But perhaps it's not necessary. The difference as far as this conversation is concerned is that Levity has been renamed to RuntimeRep. I think this is an improvement, because now it's not terribly hard to explain: --- 1. Types of kind * have values represented by pointers. This is the vast majority of data in Haskell, because almost everything in Haskell is boxed. 2. But sometimes, we don't care how a value is represented. In this case, we can be polymorphic in the choice of representation, just like `length` is polymorphic in the choice of list element type. 3. ($) works with functions whose result can have any representation, as succinctly stated in the type. Note that the argument to the function must be boxed, however, because the implementation of ($) must store and pass the argument. It doesn't care at all about the result, though, allowing for representation-polymorphism. In aid of this explanation, we can relate this all to Java. The reference types in Java (e.g., Object, int[], Boolean) are all like types of kind *. The primitive types in Java (int, boolean, char) do not have kind *. Java allows type abstraction (that is, generics) only over the types of kind *. Haskell is more general, allowing abstraction over primitive types via representation polymorphism. --- Could this all be explained to a novice programmer? That would be a struggle. But it could indeed be explained to an intermediate programmer in another language just learning Haskell. For point of comparison, Java is widely used as a teaching language. And yet one of the simplest programs is public class HelloWorld { public static void main(String[] args) { System.out.println("Hello, world!"); } } When I taught Java (I taught high-school full time for 8 years), I would start with something similar to this and have to tell everyone to ignore 90% of what was written. My course never even got to arrays and `static`! That was painful, but everyone survived. This is just to point out that Haskell isn't the only language with this problem. Not to say we shouldn't try to improve! We're in a bit of a bind in all this. We really need the fancy type for ($) so that it can be used in all situations where it is used currently. The old type for ($) was just a plain old lie. Now, at least, we're not lying. So, do we 1) lie, 2) allow the language to grow, or 3) avoid certain growth because it affects how easy the language is to learn? I don't really think anyone is advocating for (3) exactly, but it's hard to have (2) and not make things more complicated -- unless we have a beginners' mode or other features in, say, GHCi that aid learning. As I've said, I'm in full favor of adding these features. Richard On Feb 5, 2016, at 12:55 PM, Kyle Hanson <me(a)khanson.io> wrote: > I am also happy the discussion was posted here. Although I don't teach Haskell professionally, one of the things I loved to do was show people how simple Haskell really was by inspecting types and slowly putting the puzzle pieces together. > > Summary of the problem for others: > From Takenobu Tani > Before ghc7.8: > > Prelude> :t foldr > foldr :: (a -> b -> b) -> b -> [a] -> b > > Prelude> :t ($) > ($) :: (a -> b) -> a -> b > > Beginners should only understand about following: > > * type variable (polymorphism) > > > After ghc8.0: > > Prelude> :t foldr > foldr :: Foldable t => (a -> b -> b) -> b -> t a -> b > > Prelude> :t ($) > ($) > :: forall (w :: GHC.Types.Levity) a (b :: TYPE w). > (a -> b) -> a -> b > > > With this change it looks like I will no longer be able to keep `$` in my toolbox since telling a beginner its "magic" goes against what I believe Haskell is good at, being well defined and easy to understand (Not well defined in terms of Types but well defined in terms of ability to precisely and concisely explain and define whats going on). > > It looks like where the discussion is going is to have these types show by default but eventually have an Alternative prelude for beginners. > > From Richard Eisenberg: > - It's interesting that the solution to the two problems Takenobu pulls out below (but others have hinted at in this thread) is by having an alternate Prelude for beginners. I believe that having an alternate beginners' Prelude is becoming essential. I know I'm not the first one to suggest this, but a great many issues that teachers of Haskell have raised with me and posts on this and other lists would be solved by an alternate Prelude for beginners. > I don't like the idea of fragmenting Haskell into "beginners" and "advanced" versions. Its hard enough to get people to believe Haskell is easy. If they see that they aren't using the "real" prelude, Haskell will still be this magic black box that is too abstract and difficult to understand. If they have to use a "dumbed down" version of Haskell to learn, its not as compelling. > > There is something powerful about using the same idiomatic tools as the "big boys" and have the tools still be able to be easy to understand.... by default. Adding complexity to the default Haskell runs the risk of further alienating newcomers to the language who have a misconception that its too hard. > > Admittedly, I am not well informed of the state of GHC 8.0 development and haven't had time to fully look into the situation. I am very interested to see where this conversation and the default complexity of Haskell goes. > > -- > Kyle > > > On Fri, Feb 5, 2016 at 8:26 AM, Tom Ellis <tom-lists-haskell-cafe-2013(a)jaguarpaw.co.uk> wrote: > On Fri, Feb 05, 2016 at 05:25:15PM +0100, Johannes Waldmann wrote: > > > What's changed? > > > > I was referring to a discussion on ghc-devs, see > > https://mail.haskell.org/pipermail/ghc-devs/2016-February/011268.html > > and mixed up addresses when replying. > > I'm glad you did, because this is the first I've heard of it! > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

10 14