- Glasgow-haskell-users

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

Alternative to importing GHC.TypeLits?
by Chris Martin 31 Mar '17

31 Mar '17

The GHC manual gives code examples that import GHC.TypeLits. The documentation on that module seems to request that users /not/ import it ... > This module is an internal GHC module. [...] The programmer interface for working with type-level naturals should be defined in a separate library. ... although I'm not sure what "what be" means here. Does that mean it's a to-do item, and that there will eventually be a separate library, but that we should use this "internal" library directly for now? --- GHC manual: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… GHC.TypeLits: https://www.stackage.org/haddock/lts-8.5/base-4.9.1.0/GHC-TypeLits.html

2 1

Re: DeriveFoldable treatment of tuples is surprising
by Anthony Clayden 25 Mar '17

25 Mar '17

> On Wed Mar 22 13:54:05 UTC 2017, Twan van Laarhoven wrote: >> On 2017-03-21 21:34, David Feuer wrote: >> This seems much too weird: >> >> *> :set -XDeriveFoldable >> *> data Foo a = Foo ((a,a),a) deriving Foldable >> *> length ((1,1),1) >> 1 >> *> length $ Foo ((1,1),1) >> 3 Hmm. *> length $ Just ((1, 1), 1) 1 *> length $ Just (1, 1) 1 *> length (1, 1) 1 > This is not unique to tuples, consider: > > :set -XDeriveFoldable > > data Foo a = Foo [[a]] deriving Foldable > > length [[1,2]] > 1 > > length $ Foo [[1,2]] > 2 > length $ Just [[1, 2]] 1 Does the behaviour of other methods within Foldable seem surprising for DeriveFoldable Foo a = Foo ((a, a), a)? Did the FTP change touch DeriveFoldable? (Silly question, yes it must have: `length` didn't used to be in Foldable.) > On Tue Mar 21 21:29:20 UTC 2017, Edward Kmett wrote: > In general I think the current behavior is the least surprising as it > "walks all the a's it can" and is the only definition compatible with > further extension with Traversable. Right now there are no instances > provided by base that violate the "walk all the a's" intuition ?? Are there instances in base where the `a` appears more than once on RHS? I can see only List and Array. How would I have formed that "walk all the a's" intuition? (For most of the Prelude instances, `length`s result is hard-coded as 0 or 1.) *> length (((1, 2), 3) :: Num a => ((a, a), a)) 1 Doesn't seem to "walk all the a's" there. I find pretty much all of these results surprising. (Admittedly for different reasons in different cases.) I think this is a good reason `length` should not be in Foldable. "lengthiness" just doesn't fit the abstraction. AntC

1 0

WARNING in hptSomeThingsBelowUs
by Ben Franksen 22 Mar '17

22 Mar '17

This is what I get after removing a file from the working tree and also from the cabal file for the project and then rebuild. WARNING in hptSomeThingsBelowUs missing module Darcs.Util.Environment Probable cause: out-of-date interface files I am using cabal new-build. Cabal folks tell me this is a ghc problem. I am using ghc-7.10.3. Cheers Ben

2 2

DeriveFoldable treatment of tuples is surprising
by David Feuer 22 Mar '17

22 Mar '17

This seems much too weird: *> :set -XDeriveFoldable *> data Foo a = Foo ((a,a),a) deriving Foldable *> length ((1,1),1) 1 *> length $ Foo ((1,1),1) 3 I've opened Trac #13465 [*] for this. As I write there, I think the right thing is to refuse to derive Foldable for a type whose Foldable instance would currently fold over components of a tuple other than the last one. I could go either way on Traversable instances. One could argue that since all relevant components *must* be traversed, we should just go ahead and do that. Or one could argue that we should be consistent with Foldable and refuse to derive it. What do you all think? [*] https://ghc.haskell.org/trac/ghc/ticket/13465

6 6