- Glasgow-haskell-users

8.2.1-rc2 upgrade report
by Alberto Valverde 08 Jun '17

08 Jun '17

Hi, I've finally managed to upgrade all the dependencies of the proprietary app I mentioned some days ago in this list and there are good and bad differences I've noticed between 8.0.2 that I'd like to share. The bad ----------- * An optimized cold build (-O2) is about 3 times slower (~53s vs. ~2m55s) and consumes more memory (~2Gb vs. ~7Gb) at it's peak. The good ------------- * An un-optimized cold build (-O0) takes about the same time (~21s, phew! :) It's maybe even slightly faster with 8.2 (too few and badly taken measurements to really know, though) * The optimized executable is slightly faster and allocates less memory. For this app it makes up for the performance regression of the optimized build (which is almost always done by CI), IMHO. I did only a couple of runs and only wrote down [1] the last run results (which were similar to the previous results) so take these observations with a grain of salt (except maybe the optimized build slowdown, which doesn't have much margin for variance to be skewing the results). I also measured the peak memory usage by observing "top". In case gives a clue: The app is a multi-threaded 2D spread simulator which deals with many mmapped Storable mutable vectors and has been pretty optimized for countless hours (I mean by this that it has (too) many INLINE pragmas. Mostly on polymorphic functions to aid in their specialization). I think some of this information can be deduced from the results I'm linking at the footer. I believe the INLINEs are playing a big part of the slowdown since the slowest modules to compile are the "Main" ones which put everything together, along with the typical lens-th-heavy "Types" ones. I'd like to help by producing a reproducible and isolated benchmark or a better analysis or ... so someone more knowledgeable than me on GHC internals can someday hopefully attack the regression. Any pointers on what would help and where can I learn to do it? Thanks! [1] https://gist.github.com/albertov/46fbb13d940f67a569f9a25c1cb8154c

2 2

[ANNOUNCE] GHC 8.2.1 release candidate 2
by Ben Gamari 19 May '17

19 May '17

Hello everyone, The GHC team is very pleased to announce the second candidate of the 8.2.1 release of the Glasgow Haskell Compiler. Source and binary distributions are available at https://downloads.haskell.org/~ghc/8.2.1-rc2/ This is the second of what will likely be either two or three release candidates leading up the final 8.2.1 release. This release will feature, * A new type-indexed Typeable implementation * The long awaited Backpack * Deriving strategies for disambiguating DeriveAnyClass, GeneralizedNewtypeDeriving, and stock mechanisms * Overloaded record fields * Improved compiler performance * Better code generation through more robust tracking of join points * Compact regions for more efficient garbage collection and serialization * Better support for machines with non-uniform memory architectures * More robust support for levity (e.g. RuntimeRep) polymorphism * A simple interface for streaming eventlog data from live processes * Further refinement of DWARF support This candidate fixes most of the issues present in release candidate one including, * #13233: typePrimRep panic while compiling GHC with profiling enabled * #13509: type error involving unboxed tuples * #13426: compile-time memory-usage regression * #13560: Windows binary distributions carry absolute paths to toolchain * #13585: Control.Lens.Wrapped.ala causes compiler panic * #13623: Join points produce bad code for stream fusion As always, please let us know if you have difficulty. Thanks to everyone who has contributed! Happy testing, - Ben

3 5

Re: [ANNOUNCE] GHC 8.2.1 release candidate 2
by Ben Gamari 16 May '17

16 May '17

Markus Trippelsdorf <markus(a)trippelsdorf.de> writes: > On 2017.05.15 at 22:47 -0400, Ben Gamari wrote: >> >> >> The GHC team is very pleased to announce the second candidate of the >> 8.2.1 release of the Glasgow Haskell Compiler. Source and binary >> distributions are available at >> >> https://downloads.haskell.org/~ghc/8.2.1-rc2/ >> >> This is the second of what will likely be either two or three release >> candidates leading up the final 8.2.1 release. This release will >> feature, >> >> As always, please let us know if you have difficulty. Thanks to everyone >> who has contributed! >> >> Happy testing, > > Unfortunately xmobar segfaults from time to time when build with > 8.2.1-rc2, e.g.: > Thanks for your report! Segfaults are certainly no good. Do you know whether these are also reproducible with rc1? What version of xmobar are you using? What does your configuration look like? I've started an xmobar built from upstream's master branch with an empty configuration to see whether this is reproducible locally. I've opened #13707 to track this. Cheers, - Ben

1 0

Unused import warning on re-export
by Yitzchak Gale 15 May '17

15 May '17

I have a module A with no export list, and a function f which from the API point of view should part of the export list of A. But f must be defined in module B, not module A, due an import cycle. I added this line in module A to re-export f from A: import B as A (f) This resulted in an unused import warning. That is a problem for us - we keep our large code base clean of warnings as a policy. Is there a reason GHC considers this case an unused import? It seems that the use of the import is explicitly stated right within the import itself. Should I submit a ticket for this? Thanks, Yitz

3 3

Re: Superclass Equality constraints cp FunDeps
by Anthony Clayden 08 May '17

08 May '17

Now that I've got the bit between my teeth ... Superclass constraints are not subject to the Paterson conditions. IOW I can write superclass constraints that are not permitted as instance constraints. (Superclass constraints are required to be non-cyclic, which ensures they're terminating.) Is that worth adding to the docos? Something like this is OK: > class (F a b ~ b) => C a b ... > -- equivalently > class (D a b b) => C a b ... Can I think of a use for that? Maybe ... Sometimes even though you have a type function, you can use knowledge of the result to 'improve' the parameters. The classic case is adding type-level Naturals. Maybe even type-level Boolean And: - if the result is True, so must be the params. - if the result is False, and you know one param is True, the other must be False. - but that can't be a function, because if the result is False and you know one param is False, that tells nothing about the other param. AntC > > On Sun Apr 30 19:45:34 UTC 2017, Richard Eisenberg > wrote: > > > Documentation is just about always suboptimal -- but the > > best people to suggest concrete improvements are those > > who were confused to begin with. So, by all means, > > submit patches! > > OK. Done. See #13657. >

2 1

Re: Superclass Equality constraints cp FunDeps
by Anthony Clayden 07 May '17

07 May '17

> On Sun Apr 30 19:45:34 UTC 2017, Richard Eisenberg wrote: > Documentation is just about always suboptimal -- but the > best people to suggest concrete improvements are those who > were confused to begin with. So, by all means, submit > patches! Thanks for the invite ;-). OK. Done. See #13657. I've put suggested wording, please improve! The trickier problem is where to put the wording; the 'feature' is really at the intersection of several extensions. > > Some relevant discussion on this point is on > https://ghc.haskell.org/trac/ghc/ticket/10431 > I've linked my ticket to that one. AntC > > > On Apr 30, 2017, at 3:35 PM, Brandon Allbery wrote: >>> On Sun, Apr 30, 2017 at 3:31 PM, Richard Eisenberg wrote: >>>> On Apr 30, 2017, at 6:37 AM, Anthony Clayden wrote: >>>> Is that behaviour officially documented somewhere? >>> Not that I can find. Documentation on functional >>> dependencies is somewhat lacking. This may be >>> because fundeps has received little love of late.

1 0

Re: Superclass Equality constraints cp FunDeps
by Anthony Clayden 07 May '17

07 May '17

> On Sun Apr 30 19:35:17 UTC 2017 Brandon Allbery wrote: >> On Sun, Apr 30, 2017 at 3:31 PM, Richard Eisenberg wrote: >>> >>> On Apr 30, 2017, at 6:37 AM, Anthony Clayden wrote: >>> Is that behaviour officially documented somewhere? >> >> Not that I can find. ... > > ... the originally cited behavior of > equality constraints could also stand to be documented. .. Thanks Brandon, I've added a request to #10431 [q.v.]. Actually, the required flags are documented, just in an obscure place. Anyway it's not too bad: GHC's error message tells you what to do. AntC

1 0

ConstraintKinds seems to be automatically enabled
by Wolfgang Jeltsch 05 May '17

05 May '17

Hi! In my previous e-mail, I showed some code that uses the Constraint kind. I forgot to enable the ConstraintKinds extension though, but GHC 8.0.1 did not complain. Is this a bug? All the best, Wolfgang

3 3

Re: Superclass Equality constraints cp FunDeps
by Anthony Clayden 30 Apr '17

30 Apr '17

> On at Apr 29 05:55:14 UTC 2017, Anthony Clayden wrote: > ... > So should I reasonably have known that > a superclass constraint > with FunDeps on the superclass > induces FunDeps on the sub-class > without explicitly needing to declare so? > > (I'm not complaining, more surprised/impressed.) > >From experimenting, FunDeps seem to come through from a superclass of a superclass of a superclass of the class. This from David Feuer says http://stackoverflow.com/questions/35252562/find-an-element-in-an-hlist/352… "superclass context is critical .... GHC always commits to an instance before checking the instance constraints, but it doesn't even try to find an instance until after solving the superclass constraints. So we need to use the superclass constraint to fix ..." Presumably that's the mechanism that induces FunDeps from supeclass constraints. Is that behaviour officially documented somewhere? (I remember when Type Families and (~) Constraints were first released, they weren't available superclass. Then there were a couple of releases you could put superclass constraints, but they weren't effective.) AntC

3 3

Re: Superclass Equality constraints cp FunDeps
by Anthony Clayden 29 Apr '17

29 Apr '17

> On Sat Apr 29 02:23:10 UTC 2017, Richard Eisenberg wrote: > > I'm not quite sure what a restriction on (~) might be, Thanks Richard, I was thinking that FunDeps are restricted to bare type vars. I can't write either of these: > class C a b c | a -> (b, c) -- per my O.P. (~) > class C a b c | a -> (b c) So it's the one place where type vars `b c` like this: > class C a b c | a -> b c doesn't mean applying `b` to `c`. > but (~) is effectively declared as > > > class a ~ b | a -> b, b -> a > > So I agree with your observations. Aha! So I could equivalently go: > class EqC a b | a -> b, b -> a > > class (EqC a (b, c)) => C a b c where ... > -- needs FlexibleInstances And that does indeed work equivalently to the (~). Again, I haven't put FunDeps on class `C`. So should I reasonably have known that a superclass constraint with FunDeps on the superclass induces FunDeps on the sub-class without explicitly needing to declare so? (I'm not complaining, more surprised/impressed.) AntC > > On Apr 27, 2017, at 8:14 PM, Anthony Clayden > > <anthony_clayden(a)clear.net.nz> wrote: > > The docos say [User Guide 10.14.1. on Equality > > Constraints] > >> Equality constraints can also appear in class and > > instance contexts. > >> The former enable a simple translation of programs > >> using functional dependencies into programs using > > family synonyms instead. > > > http://downloads.haskell.org/~ghc/8.0.2/docs/html/users_guide/glasgow_exts.… > > > > And the forms of constraint seem quite sophisticated. > > I was surprised (pleased) I could do this: > > > > {-# LANGUAGE MultiParamTypeClasses, TypeFamilies, > > FlexibleInstances #-} > > > > type family F a > > > > class (F a ~ (b, c) ) => C a b c where -- (b c) > > !! f1 :: a -> b > > f2 :: a -> c > > > > Uses of `f1` happily improve the type for `b`. > > Uses of `f2` happily improve the type for `c`. > > > > But I didn't declare a Functional Dependency. > > (It seems to do no harm if I add `| a -> b c`.) > > > > GHC's behaviour seems stronger than a "simple > > translation". It seems entirely equivalent to a FunDep. > > > > Or is there something I'm missing? > > (I could have overlapping instances, > > but only providing the equations for > > type family `F` are confluent.) > > > > Are there restrictions on the form of Equality > > Constraints to get them to behave as FunDeps? > > (It's not merely a bare typevar on one side.) > > > > AntC > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users(a)haskell.org > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >

1 0