May 2017 - Glasgow-haskell-users

[ANNOUNCE] GHC 8.2.1 release candidate 1
by Ben Gamari 03 Oct '17

03 Oct '17

Hello everyone, The GHC team is very pleased to announce the first 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-rc1/ This is the first of a few 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 Unfortunately there are still a few known issues in this release, including a few compiler panics (#13233, #13509) and a memory leak in the simplifier (#13426) which may adversely affect heap sizes and compilation time for some modules. This memory leak unfortunately made it impossible to provide a 32-bit Windows distribution for this candidate; this will be resolved in -rc2. As always, please let us know if you have difficulty. Thanks to everyone who has contributed to this release! Happy testing, - Ben

3 4

Untouchable type variables
by Wolfgang Jeltsch 19 Jun '17

19 Jun '17

Hi! Today I encountered for the first time the notion of an “untouchable” type variable. I have no clue what this is supposed to mean. A minimal example that exposes my problem is the following: > {-# LANGUAGE Rank2Types, TypeFamilies #-} > > import GHC.Exts (Constraint) > > type family F a b :: Constraint > > data T b c = T > > f :: (forall b . F a b => T b c) -> a > f _ = undefined This results in the following error message from GHC 8.0.1: > Untouchable.hs:9:6: error: > • Couldn't match type ‘c0’ with ‘c’ > ‘c0’ is untouchable > inside the constraints: F a b > bound by the type signature for: > f :: F a b => T b c0 > at Untouchable.hs:9:6-37 > ‘c’ is a rigid type variable bound by > the type signature for: > f :: forall a c. (forall b. F a b => T b c) -> a > at Untouchable.hs:9:6 > Expected type: T b c0 > Actual type: T b c > • In the ambiguity check for ‘f’ > To defer the ambiguity check to use sites, enable AllowAmbiguousTypes > In the type signature: > f :: (forall b. F a b => T b c) -> a I have no idea what the problem is. The type of f looks fine to me. The type variable c should be universally quantified at the outermost level. Why does the type checker even introduce a type variable c0? All the best, Wolfgang

4 4

[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 06 May '17

06 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 06 May '17

06 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