- ghc-devs - Haskell.org

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

Adding rules in a plugin?
by Conal Elliott 11 Feb '16

11 Feb '16

I'm writing a GHC plugin that generates new rules. The top-level identifier for the new rules' LHSs is always the same and is imported from another module. One of the arguments in the rule's LHSs, however, is defined in that module. I'm creating rules and adding them to the mg_rules of the module's ModGuts. I don't see them in the .hi files (viewed with "ghc --show-iface Foo.hi"), and they're not getting found in modules that import the modules where I'm trying to generate rules. Am I missing a crucial step? For instance, do I need also to use `addIdSpecialisations` with the argument identifiers, and if so, need I replace all instances of those identifiers in the module or just some of them? Thanks, -- Conal

2 2

Making a core app with a function having context in core2core plugin?
by Magesh B 11 Feb '16

11 Feb '16

Hi GHC Devs, Is it possible to make a core app with a function having contexts? For example, let us take showable :: P.Show a => a -> String showable = P.show Say, I would like to app showable with (Just 'a') in the core, which requires the following code showable @ (Maybe Char) *($fShowMaybe @ Char $fShowChar)* (Just @ Char (C# 'a')) But I couldn't find a way to construct the dictionary required by showable function myself in the core. Is there any ghc api using which I can get the required dictionary for a particular type (in the above case, Dictionary for Show instance of Maybe Char). Regards, Magesh B

1 0

problem compiling GHC 8.0.1 release candidate 2 src on Apple
by George Colpitts 07 Feb '16

07 Feb '16

"/usr/local/bin/ghc" -M -static -H32m -O -Wall -package-db libraries/bootstrapping.conf -this-unit-id terminfo-0.4.0.2 -hide-all-packages -i -ilibraries/terminfo/. -ilibraries/terminfo/dist-boot/build -ilibraries/terminfo/dist-boot/build/autogen -Ilibraries/terminfo/dist-boot/build -Ilibraries/terminfo/dist-boot/build/autogen -Ilibraries/terminfo/. -optP-include -optPlibraries/terminfo/dist-boot/build/autogen/cabal_macros.h -package-id base-4.9.0.0 -Wall -XHaskell2010 -no-user-package-db -rtsopts -fno-warn-unused-imports -fno-warn-deprecated-flags -odir libraries/terminfo/dist-boot/build -hidir libraries/terminfo/dist-boot/build -stubdir libraries/terminfo/dist-boot/build -dep-makefile libraries/terminfo/dist-boot/build/.depend-v.haskell.tmp -dep-suffix "" -include-pkg-deps libraries/terminfo/./System/Console/Terminfo.hs libraries/terminfo/./System/Console/Terminfo/Base.hs libraries/terminfo/./System/Console/Terminfo/Cursor.hs libraries/terminfo/./System/Console/Terminfo/Color.hs libraries/terminfo/./System/Console/Terminfo/Edit.hs libraries/terminfo/./System/Console/Terminfo/Effects.hs libraries/terminfo/./System/Console/Terminfo/Keys.hs ghc: unrecognised flag: -this-unit-id Usage: For basic information, try the `--help' option. make[1]: *** [libraries/terminfo/dist-boot/build/.depend-v.haskell] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv -fno-builtin") ,("C compiler command","/usr/local/bin/gcc") ,("C compiler flags"," -m64 -fno-stack-protector") ,("C compiler link flags"," -m64") ,("Haskell CPP command","/usr/local/bin/gcc") ,("Haskell CPP flags","-E -undef -traditional") ,("ld command","/usr/bin/ld") ,("ld flags"," -arch x86_64") ,("ld supports compact unwind","YES") ,("ld supports build-id","NO") ,("ld supports filelist","YES") ,("ld is GNU ld","NO") ,("ar command","/usr/bin/ar") ,("ar flags","clqs") ,("ar supports at file","NO") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("cross compiling","NO") ,("target os","OSDarwin") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","True") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","8.0.0.20160111") ,("Project Git commit id","497454fc6610d67a2b2cd7902390c6497bddb483") ,("Booter version","7.10.2") ,("Stage","2") ,("Build platform","x86_64-apple-darwin") ,("Host platform","x86_64-apple-darwin") ,("Target platform","x86_64-apple-darwin") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("RTS expects libdw","NO") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Support reexported-modules","YES") ,("Support thinning and renaming package flags","YES") ,("Requires unified installed package IDs","YES") ,("Uses package keys","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("GHC Profiled","NO") ,("Leading underscore","YES") ,("Debug on","False") ,("LibDir","/usr/local/lib/ghc-8.0.0.20160111") ,("Global Package DB","/usr/local/lib/ghc-8.0.0.20160111/package.conf.d") ] On Sun, Feb 7, 2016 at 2:13 PM, Ben Gamari <ben(a)well-typed.com> wrote: > > 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 > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > >

2 1

StgCase - are LiveVars and SRT fields going to be used?
by Ömer Sinan Ağacan 06 Feb '16

06 Feb '16

Hi all, This is how case expression in STG currently defined: | StgCase (GenStgExpr bndr occ) (GenStgLiveVars occ) (GenStgLiveVars occ) bndr SRT AltType [GenStgAlt bndr occ] The GenStgLiveVars and SRT fields are never used anywhere in the compiler (except the printer). So the question is, I'm assuming those were used at some point, but are they going to be used in the future? Or can I just delete those? As a proof of concept, I just compiled GHC using this: | StgCase (GenStgExpr bndr occ) bndr AltType [GenStgAlt bndr occ] Normally this is not a big deal, but I'm doing lots of STG-to-STG transformations nowadays, and I have to keep those field updated which is annoying as those are never going to be used (I can't even know if I'm doing it right), or leave those `undefined` which is not a good practice.

2 4

Re: New type of ($) operator in GHC 8.0 is problematic
by ghc-devs＠stefan-klinger.de 06 Feb '16

06 Feb '16

Hi there, I'm teaching Haskell to 2nd semester computer science students, and I have been teaching Haskell since 2006. While I certainly do appreciate the constant developement of Haskell, and GHC, I'm becoming more and more concerned about the learning curve involved. For our students it is an entirely new concept that “Application” can be an operator. They are just learning about associativity. `foldl` and `foldr` are *baffling* concepts to them. They have never thought of functions being values. They have never looked at a strict type system. Having `Foldable` pop up last year already was not optimal, and to be honest, this ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) -> a -> b is a disaster for teaching — Sorry. Richard, thank you very much for your elaborate statement. The problem I see with a `BeginnersPrelude` is that it will either outdate, or create a bubble escaping from which is so painful that most new Haskell programmers will hesitate to take the step. GHC developement will carry on, more and more things being hidden behind `BeginnersPrelude` automatically. We will end up educating Beginners that will want to stay beginners. I'd personally wish for a `-fdefault-levity` switch, but I do not oversee all the consequences right now. I know it puts load on you, but this actually just tells you that the language you're building became a bit less learnable, maybe it's good to be aware of that. Kind regards Stefan -- http://stefan-klinger.de o/X Send plain text messages only, not exceeding 32kB. /\/ \

2 1

Re: [GHC] #7803: Superclass methods are left unspecialized
by Eric Crockett 06 Feb '16

06 Feb '16

https://ghc.haskell.org/trac/ghc/ticket/7803#comment:12 On Sat, Feb 6, 2016 at 11:14 AM, GHC <ghc-devs(a)haskell.org> wrote: > #7803: Superclass methods are left unspecialized > -------------------------------------+------------------------------------- > Reporter: akio | Owner: > Type: bug | Status: new > Priority: normal | Milestone: > Component: Compiler | Version: 7.6.2 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: > Type of failure: Compile-time | Unknown/Multiple > performance bug | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > -------------------------------------+------------------------------------- > > Comment (by bgamari): > > I've started a pair of builds; I'll put up nofib results once they have > finished. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7803#comment:12> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 1

Re: [Haskell-cafe] New type of ($) operator in GHC 8.0 is problematic
by Ben Gamari 06 Feb '16

06 Feb '16

Tom Ellis <tom-lists-haskell-cafe-2013(a)jaguarpaw.co.uk> writes: > On Fri, Feb 05, 2016 at 07:19:25PM +0000, Tom Ellis wrote: >> On Fri, Feb 05, 2016 at 01:13:23PM -0500, Richard Eisenberg wrote: >> > 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. >> >> Is there a list of situations where ($) is used currently that give rise to >> this need? > > Does anyone have any idea about this? What is it about ($) that means it > needs a new funky type whereas (apparently) nothing else does? The first (albeit rather unconvincing) example I can think of is be something like, getI# :: Int -> Int# getI# (I# n#) = n# n# :: Int# n# = getI# $ 5 + 8 Richard likely has something a bit less contrived though. This does raise the question of why ($) is generalized, yet (.) is not, (.) :: forall (l :: Levity) a b (c :: TYPE l). (b -> c) -> (a -> b) -> (a -> c) (.) f g x = f (g x) Cheers, - Ben

1 0