April 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

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

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

29 Apr '17

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

2 1

join points and stream fusion?
by Christian Höner zu Siederdissen 28 Apr '17

28 Apr '17

Dear all, have some of you experienced bad code generation in ghc-8.2-rc1 in combination with stream fusion from the vector package? Unfortunately, the problem occurs with ADPfusion code which means no simple example, but I'm asking because of the following core below. In ghc-8.0 I have nice core, here however constructor specialization has not happened, neither with the Left/Right nor with the SPEC. The running time in ghc-8.0 is 2.6 seconds, in rc-1 10.9 seconds. Best, Christian joinrec { $wfoldlM'_loop2_s1uf4 $wfoldlM'_loop2_s1uf4 w_s1ueX ww1_s1uf2 w1_s1ueZ = case w_s1ueX of { __DEFAULT -> case w1_s1ueZ of { Left sa_au90 -> case sa_au90 of { Left sa1_XuNq -> case sa1_XuNq of { Left sa2_XuNe -> case sa2_XuNe of { SL s2_alTo k_alTp -> case k_alTp of { __DEFAULT -> jump $wfoldlM'_loop2_s1uf4 SPEC ww1_s1uf2 lvl211_s1IDG; 1# -> jump $wfoldlM'_loop2_s1uf4 SPEC ww1_s1uf2 (Left (Left (Left (SR s2_alTo))))

2 4

Option for Combinator Graphs in GHC?
by Mark Robert Nixon 21 Apr '17

21 Apr '17

Does the GHC compiler generate combinator terms/graphs of Haskell programs? Combinator terms are often derived during compilation for purposes of optimization by way of normal order graph reduction. But does GHC output, e.g., as an option, a given Haskell program's entire combinator term/graph? Very respectfully, Mark R. Nixon

1 0

RE: Why isn't this Overlapping?
by Anthony Clayden 18 Apr '17

18 Apr '17

> On Tue Apr 18 10:31:30 UTC 2017, Simon Peyton Jones wrote: > > Moreover, as discussed in the user manual section, > GHC doesnt complain about overlapping instances at the instance decl, > but rather where the instances are used. Thank you Simon, yes I knew that, so I'd written a usage (just didn't bother putting it in the message ): foo :: (TypeEq a a' b) => a -> a' -> String foo _ _ = "blah" x = foo 'c' "String" > Thats why there is no overlap complaint here I didn't get a complaint about `x`, contrary to what I expected. On trying again just now: y = foo 'c' 'd' GHC _does_ complain of overlap. I apologise for the distraction. AntC >> On 18 April 2017 01:50, Iavor Diatchki wrote >> these two instances really should be rejected as they violate the FD of the class: >> we can derive `TypeEq a a True` using the first instance and `TypeEq a a False` >> using the second one. Unfortunately, the check that we are using >> to validate FDs when `UndecidableInstances` is on, >> is not quite correct (relevant tickets are #9210 and #10675 >> where there are similar examples). >>> On Sun, Apr 16, 2017 at 12:13 AM, Anthony Clayden wrote: >>> --ghc 7.10 or 8.0.1 >>> >>> {-# LANGUAGE DataKinds, KindSignatures, GADTs, >>> MultiParamTypeClasses, >>> FunctionalDependencies, FlexibleInstances, >>> UndecidableInstances, NoOverlappingInstances #-} >>> class TypeEq a a' (b :: Bool) | a a' -> b >>> >>> instance (b ~ True) => TypeEq a a b >>> instance (b ~ False) => TypeEq a a' b >>> Those two instance heads are nearly identical, >>> surely they overlap? >> And for a type-level type equality test, >>> they must be unifiable. >>> But GHC doesn't complain. >>> >>> If I take off the FunDep, then GHC complains. >>> >>> AFAICT none of those extensions imply Overlaps, >>> but to be sure I've put NoOverlapping.

1 0

Why isn't this Overlapping?
by Anthony Clayden 18 Apr '17

18 Apr '17

--ghc 7.10 or 8.0.1 {-# LANGUAGE DataKinds, KindSignatures, GADTs, MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances, UndecidableInstances, NoOverlappingInstances #-} class TypeEq a a' (b :: Bool) | a a' -> b instance (b ~ True) => TypeEq a a b instance (b ~ False) => TypeEq a a' b Those two instance heads are nearly identical, surely they overlap? And for a type-level type equality test, they must be unifiable. But GHC doesn't complain. If I take off the FunDep, then GHC complains. AFAICT none of those extensions imply Overlaps, but to be sure I've put NoOverlapping. AntC

3 2

Re: Why isn't this Overlapping?
by Anthony Clayden 18 Apr '17

18 Apr '17

> On Tue Apr 18 00:50:20 UTC 2017, Iavor Diatchki wrote: > > these two instances really should be rejected as they > violate the FD of the class: we can derive `TypeEq a a > True` using the first instance and `TypeEq a a False` > using the second one. Unfortunately, the check that we > are using to validate FDs when `UndecidableInstances` is > on, is not quite correct (relevant tickets are #9210 and > #10675 where there are similar examples). > Thanks Iavor, it was a propos those tickets I'm asking. See my comments on #10675 -- we'll have to agree to disagree on "not quite correct". (If you want to ban instance selecting on type equality, you'll make a lot of people grumpy.) My surprise here is why GHC doesn't complain about overlaps. (Separately from whether it's doing the right thing.) Here's another example [GHC 7.10] and here I agree the FunDep consistency is well broken, again needs UndecidableInstances: {-# LANGUAGE MultiParamTypeClasses, GADTs, FunctionalDependencies, FlexibleInstances, UndecidableInstances #-} class C a b | a -> b where foo :: a -> b -> String instance C Int Bool where foo _ _ = "Bool called" {- So far so good: no bare typevars in instance head; don't need UndecidableInstances for that -} instance (b ~ Char) => C Int b where foo _ _ = "b ~ Char called" I can't write that instance head `C Int Char`. GHC complains inconsistent with FunDep [quite correct]. But I can call `foo (5 :: Int) 'c'` ==> "b ~ Char called". If I call `foo (5 :: Int) undefined` ==> GHC complains of overlaps. [I would say fair enough too, except ...] If I change the instance to instance {-# OVERLAPPABLE #-} (b ~ Char) => C Int b where .. Then `foo (5 :: Int) undefined` ==> "Bool called" So GHC both uses the FunDep to improve the type, and uses the improvement to select an instance; and yet seems blind to FunDep inconsistencies in the instance decls. AntC > > > On Sun, Apr 16, 2017 at 12:13 AM, Anthony Clayden wrote: > > > > --ghc 7.10 or 8.0.1 > > > > {-# LANGUAGE DataKinds, KindSignatures, GADTs, > > MultiParamTypeClasses, > > FunctionalDependencies, FlexibleInstances, > > UndecidableInstances, > > NoOverlappingInstances #-} > > > > class TypeEq a a' (b :: Bool) | a a' -> b > > > > instance (b ~ True) => TypeEq a a b > > instance (b ~ False) => TypeEq a a' b > > > > Those two instance heads are nearly identical, surely > > they overlap? > > And for a type-level type equality test, they must be > > unifiable. > > But GHC doesn't complain. > > > > If I take off the FunDep, then GHC complains. > > > > AFAICT none of those extensions imply Overlaps, > > but to be sure I've put NoOverlapping. > > > > > > 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