- Glasgow-haskell-users

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

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