- ghc-devs - Haskell.org

Re: More Higher-Kinded Typeclass Instances
by Ryan Scott 29 Mar '16

29 Mar '16

Well, if we're going to be thorough, we need to also get: * Tuple types * All (* -> *)-kinded datatypes in Data.Monoid * Data.Type.Equality.(:~:) and Data.Type.Coercion.Coercion * Fixed * ST, STRef * Chan * MVar, IORef, TVar A lot of these types' existing Eq/Ord/Read/Show instances are currently derived, however, and you might find it incredibly tedious to type all them out by hand (not to discourage you from going for it if you need them now, but we warned). Given that the window for new 8.0 features is almost closed, perhaps it would be better to wait until I've implemented an extension which derives these classes automatically? (I wanted to get such an extension implemented sooner, but time ran out. I'll try to find some time to write a wiki page proposing a design so that we can get the ball rolling soon after the 8.0 final release.) Ryan S.

2 1

instantiating visible parameters in when deriving instances
by Richard Eisenberg 29 Mar '16

29 Mar '16

Hi devs, Consider the following: > data Proxy k (a :: k) = P > deriving Functor What should happen when this is compiled? 1. Issue an error saying that `deriving` cannot instantiate visible parameters. 2. Type error: cannot match `k` with `*`. 3. Successfully produce `instance (Proxy *)`. Currently, GHC does #3. But this ends up choosing a value for a visible (i.e. explicit) parameter to Proxy. Is this a good idea? I myself have flip-flopped on this issue; see https://ghc.haskell.org/trac/ghc/ticket/11732, comments 4 and 9. I'd love to get feedback on this point. Thanks! Richard

4 3

possible tuple elimination optimization?
by George Colpitts 29 Mar '16

29 Mar '16

The following higher order function, sumh, seems to be 3 to 14 times slower than the equivalent recursive function, sumr: sumh :: Double -> Double sumh n = snd $ until ((>= n) . fst) as' (1, 0) where as' (i,s) = (i + 2, s + (-1) / i + 1 / (i + 1)) sumr :: Double -> Double sumr n = as' 1 0 where as' i s | i >= n = s | otherwise = as' (i + 2) (s + (-1) / i + 1 / (i + 1)) This is true in 7.10.3 as well as 8.0.1 so this is not a regression. From the size usage my guess is that this is due to the allocation of tuples in sumh. Maybe there is a straightforward way to optimize sumh but I couldn't find it. Adding a Strict pragma didn't help nor did use of -funbox-strict-fields -flate-dmd-anal. Have I missed something or should I file a bug? Timings from 8.0.1 rc2: ghc --version The Glorious Glasgow Haskell Compilation System, version 8.0.0.20160204 bash-3.2$ ghc -O2 -dynamic sum.hs ghc -O2 -dynamic sum.hs [1 of 1] Compiling Main ( sum.hs, sum.o ) Linking sum ... bash-3.2$ ghci Prelude> :load sum Ok, modules loaded: Main. (0.05 secs,) Prelude Main> *sumh* (10^6) -0.6931466805602525 it :: Double (*0.14 secs, 40,708,016 bytes*) Prelude Main> sumr (10^6) -0.6931466805602525 it :: Double (*0.01 secs, 92,000 bytes)* Thanks George

3 3

Re: instantiating visible parameters in when deriving instances
by Ryan Scott 28 Mar '16

28 Mar '16

> I don't really expect any of the TypeInType stuff to work with the deriving machinery. I do! And we can make -XDeriveFunctor work well with -XTypeInType regardless of which option is picked, so keep that in mind. > I think that, at the moment, for a normal deriving clause, GHC never adds in constraints (I might be wrong on this). GHC does add constraints in some cases. Here's a less dangerous-looking example: data T (a :: k) = T deriving Functor => instance Functor T The generated instance very subtly constraints k to be *. The difference in this example, however, is that k is not visible, so it feels less harmful to constrain it. > I don't know if StandaloneDeriving works with DeriveFunctor or not It does. -XStandaloneDeriving works with any flavor of deriving out there, and it's a great backdoor to get around sticky deriving issues like this (e.g., if a derived instance context would require undecidable typechecking, we bail out and tell the user to try again with -XStandaloneDeriving). I don't have a strong opinion on whether option 1, 2, or 3 is best, but if we pick option 1 or 2, I request that the error message tell the user to try -XStandaloneDeriving. Ryan S.

2 1

More Higher-Kinded Typeclass Instances
by Andrew Martin 28 Mar '16

28 Mar '16

Earlier today, I wrote Proxy's instances for Eq1, Ord1, Show1, and Read1 and they were accepted for base-4.9.0.0. All in all, the process went way more smoothly than I expected, and so I started thinking about what other types from base are currently missing these instances, and this is what I've come up with: - Down (from Data.Ord) - Complex (from Data.Complex) - Ratio (from Data.Ratio) - First, Last (from Data.Monoid) - ZipList (from Control.Applicative) - Ptr, FunPtr (from Foreign.Ptr, only Eq1 and Ord1) - StablePtr (from Foreign.StablePtr, only Eq1) - K1, U1, Par1, Rec1, etc. (from GHC.Generics) - StableName (from System.Mem.StableName, only Eq1, requested here: http://hub.darcs.net/ross/transformers/issue/17) Since most of these are trivial to implement, I'd like to try to get them in for GHC-8.0. Does anyone have in mind any other data types that would benefit from these? -- -Andrew Thaddeus Martin

1 0

GHC 8 superclass chain constraint regression
by Kosyrev Serge 28 Mar '16

28 Mar '16

Good day! It seems that GHC 8 regresses with regard to GHC 7.10, when it tries to satisfy the constraints, implied by instance context. The following does not build on GHC 8.0.1 RC2, but does on 7.10.3: > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE UndecidableInstances #-} > --{-# LANGUAGE UndecidableSuperClasses #-} -- this doesn't matter > {-# LANGUAGE UnicodeSyntax #-} > > module Foo where > > class Super a > class Super a ⇒ Left a > class Super a ⇒ Right a > instance (Left a) ⇒ Right a the error being: > • Could not deduce (Super a) > arising from the superclasses of an instance declaration > from the context: Left a > bound by the instance declaration > at repro.hs:9:10-27 > Possible fix: > add (Super a) to the context of the instance declaration > • In the instance declaration for ‘Right a’ A look through the GHC 8 status page, produced no bugs that seemed related to my uneducated guess. It also /roughly/ seems that https://phabricator.haskell.org/D1594 could possibly be related. Thanks to lyxia on #haskell for pointing that this actually works on 7.10.. -- с уважениeм / respectfully, Косырев Сергей

2 2

Re: New type of ($) operator in GHC 8.0 is problematic
by Ryan Scott 28 Mar '16

28 Mar '16

Hi Chris, The change to ($)'s type is indeed intentional. The short answer is that ($)'s type prior to GHC 8.0 was lying a little bit. If you defined something like this: unwrapInt :: Int -> Int# unwrapInt (I# i) = i You could write an expression like (unwrapInt $ 42), and it would typecheck. But that technically shouldn't be happening, since ($) :: (a -> b) -> a -> b, and we all know that polymorphic types have to live in kind *. But if you look at unwrapInt :: Int -> Int#, the type Int# certainly doesn't live in *. So why is this happening? The long answer is that prior to GHC 8.0, in the type signature ($) :: (a -> b) -> a -> b, b actually wasn't in kind *, but rather OpenKind. OpenKind is an awful hack that allows both lifted (kind *) and unlifted (kind #) types to inhabit it, which is why (unwrapInt $ 42) typechecks. To get rid of the hackiness of OpenKind, Richard Eisenberg extended the type system with levity polymorphism [1] to indicate in the type signature where these kind of scenarios are happening. So in the "new" type signature for ($): ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) -> a -> b The type b can either live in kind * (which is now a synonym for TYPE 'Lifted) or kind # (which is a synonym for TYPE 'Unlifted), which is indicated by the fact that TYPE w is polymorphic in its levity type w. Truth be told, there aren't that many Haskell functions that actually levity polymorphic, since normally having an argument type that could live in either * or # would wreak havoc with the RTS (otherwise, how would it know if it's dealing with a pointer or a value on the stack?). But as it turns out, it's perfectly okay to have a levity polymorphic type in a non-argument position [2]. Indeed, in the few levity polymorphic functions that I can think of: ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) -> a -> b error :: forall (v :: Levity) (a :: TYPE v). HasCallStack => [Char] -> a undefined :: forall (v :: Levity) (a :: TYPE v). HasCallStack => a The levity polymorphic type never appears directly to the left of an arrow. The downside of all this is, of course, that the type signature of ($) might look a lot scarier to beginners. I'm not sure how you'd want to deal with this, but for 99% of most use cases, it's okay to lie and state that ($) :: (a -> b) -> a -> b. You might have to include a disclaimer that if they type :t ($) into GHCi, they should be prepared for some extra information! Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds [2] https://ghc.haskell.org/trac/ghc/ticket/11473

20 53

Re:until, laziness, and performance
by George Colpitts 27 Mar '16

27 Mar '16

Dan, I really appreciate that you responded so quickly and took the time to explain this. Unfortunately I still don't understand. I did think of laziness as a potential source of bad performance but to me both internal functions were lazy in the second argument. Since I couldn't explain why both weren't equally slow due to laziness, I dismissed laziness as a possible source of the problem instead of questioning my understanding of laziness. I still don't understand why as' i s | i >= n = s | otherwise = as' (i + 2) (s + (-1) / i + 1 / (i + 1)) is not lazy in its second arg as it only has to evaluate it if i >= n. This seems exactly analogous to or, ||, which only needs to evaluate its second arg if its first arg is False. || is definitely lazy in its second argument. Can you explain why as' is strict in its second arg, s? Is it due to the following from, https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Demand ? For functions, it is assumed, that the result of the function is used strictly. I guess I should have checked my intuition against the compiler strictness analysis. I modified sum.hs to only have a definition of sumr, commenting out sumh and tried the various tools. The user's guide, https://downloads.haskell.org/~ghc/8.0.1-rc2/docs/html/users_guide/sooner.h…, recommends: Look for your function in the interface file, then for the third field in the pragma; it should say Strictness: ⟨string⟩. The ⟨string⟩ gives the strictness of the function’s arguments: see the GHC Commentary for a description of the strictness notation. It doesn't mention that the interface file is binary and that you need to use ghc --show-iface, e.g. ghc --show-iface sum.hi > sum.hir Doing this seems to give the wrong answer, i.e. the second arg is lazy. $was' :: Double# -> Double# -> Double# {- Arity: 2, Strictness: <S,U><*L*,U>, Inline: [0] -} Is this a bug? ghc -ddump-stranal -O sum.hs gives the right answer: as'_s25G [Occ=LoopBreaker] :: Double -> Double -> Double [LclId, Arity=2, CallArity=2, Str=DmdType <S(S),1*U(U)><*S*,1*U(U)>m {avM-><S(S),U(U)>}, Unf=Unf{Src=<vanilla>, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [20 20] 108 0}] Unfortunately the simplest way to find out doesn't give information on internal functions. I will file an ER for this: ghc -ddump-strsigs -O sum.hs [1 of 1] Compiling Main ( sum.hs, sum.o ) ==================== Strictness signatures ==================== :Main.main: Main.$trModule: m Main.main: x Main.sumr: <S(S),U(U)>m I really like your definition of until' as the solution to this. To me it seems analogous to foldl', in that it provides a way to avoid an optimization problem that may be subtle to many. I guess it is not general enough to be added to a library. The following world be general enough but it would probably be overkill: until' :: NFData a => (a -> Bool) -> (a -> a) -> a -> a until' p f = go where go x | p $!! x = x | otherwise = go (f x) Thanks again for all your help George On Sat, Mar 26, 2016 at 5:40 PM Dan Doel <dan.doel(a)gmail.com> wrote: > By the way, in case this helps your mental model, if you modify sumr to be: > > sumr n = snd $ as' 1 0 > where > as' i s > | i >= n = (i, s) > | otherwise = ... > > Then it has the same problem as sumh. Your original as' for sumr is > strict in s, but this modified one isn't. > > This shows another way to fix sumh, too. Create a version of until > that separates out the part of the state that is only for testing. > Then the until loop will be strict in the result part of the state, > and the desired optimizations will happen (in this case): > > until' p step = go > where > go t r > | p t = r > | otherwise = uncurry go $ step (t, r) > > -- Dan > > On Sat, Mar 26, 2016 at 1:50 PM, George Colpitts > <george.colpitts(a)gmail.com> wrote: > > The following higher order function, sumh, seems to be 3 to 14 times > slower > > than the equivalent recursive function, sumr: > > > > sumh :: Double -> Double > > sumh n = > > snd $ until ((>= n) . fst) as' (1, 0) > > where > > as' (i,s) = > > (i + 2, s + (-1) / i + 1 / (i + 1)) > > > > sumr :: Double -> Double > > sumr n = > > as' 1 0 > > where > > as' i s > > | i >= n = s > > | otherwise = as' (i + 2) (s + (-1) / i + 1 / (i + 1)) > > > > This is true in 7.10.3 as well as 8.0.1 so this is not a regression. From > > the size usage my guess is that this is due to the allocation of tuples > in > > sumh. Maybe there is a straightforward way to optimize sumh but I > couldn't > > find it. Adding a Strict pragma didn't help nor did use of > > -funbox-strict-fields -flate-dmd-anal. Have I missed something or should > I > > file a bug? > > > > Timings from 8.0.1 rc2: > > > > ghc --version > > The Glorious Glasgow Haskell Compilation System, version 8.0.0.20160204 > > bash-3.2$ ghc -O2 -dynamic sum.hs > > ghc -O2 -dynamic sum.hs > > [1 of 1] Compiling Main ( sum.hs, sum.o ) > > Linking sum ... > > bash-3.2$ ghci > > Prelude> :load sum > > Ok, modules loaded: Main. > > (0.05 secs,) > > Prelude Main> sumh (10^6) > > -0.6931466805602525 > > it :: Double > > (0.14 secs, 40,708,016 bytes) > > Prelude Main> sumr (10^6) > > -0.6931466805602525 > > it :: Double > > (0.01 secs, 92,000 bytes) > > > > Thanks > > George > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs(a)haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > >

2 2

Table of contents
by Simon Peyton Jones 26 Mar '16

26 Mar '16

Could the table of contents for the GHC user manual have one more level showing? Or just all levels? http://downloads.haskell.org/~ghc/master/users-guide/ I often search for things I can’t find Thanks Simon

2 1

How to prevent GHC (API) from breaking large constants into multiple top-level bindings
by Christiaan Baaij 24 Mar '16

24 Mar '16

My situation is the following, given the code: > {-# LANGUAGE GADTs, DataKinds, TypeOperators, KindSignatures #-} > module GConst where > > import GHC.TypeLits > > data Vec :: Nat -> * -> * > where > Nil :: Vec 0 a > Cons :: a -> Vec n a -> Vec (n+1) a > > infixr `Cons` > > c :: Vec 5 Int > c = 1 `Cons` 2 `Cons` 3 `Cons` 4 `Cons` 5 `Cons` Nil The output of the desugarer, 'ghc -O -fforce-recomp -fno-full-laziness -ddump-ds -dsuppress-all GConst.hs', is: > c = > ($WCons > (I# 1) > (($WCons > (I# 2) > (($WCons > (I# 3) > (($WCons (I# 4) (($WCons (I# 5) ($WNil)) `cast` ...)) `cast` ...)) > `cast` ...)) > `cast` ...)) > `cast` ... Where the constant 'c' is a single large constant. However, when I look at the output of the simplifier, 'ghc -O -fforce-recomp -fno-full-laziness -ddump-simpl -dsuppress-all GConst.hs', I see this: > c10 > c10 = I# 1 > > c9 > c9 = I# 2 > > c8 > c8 = I# 3 > > c7 > c7 = I# 4 > > c6 > c6 = I# 5 > > c5 > c5 = Cons @~ <0 + 1>_N c6 ($WNil) > > c4 > c4 = Cons @~ <1 + 1>_N c7 (c5 `cast` ...) > > c3 > c3 = Cons @~ <2 + 1>_N c8 (c4 `cast` ...) > > c2 > c2 = Cons @~ <3 + 1>_N c9 (c3 `cast` ...) > > c1 > c1 = Cons @~ <4 + 1>_N c10 (c2 `cast` ...) > > c > c = c1 `cast` ... The single constant is completely taken apart into multiple top-level bindings. I haven't given it too much thought, but I assume there are good reasons to take large constants aparts, and break them into individual top-level bindings. At least when your target is a normal CPU. Now, I'm a GHC API user, and I convert Haskell programs to digital circuits. For my use case, breaking up constants into smaller top-level bindings has completely no performance benefits at all. Actually, my compiler _inlines_ all those top-level bindings again to create a single large constant. When working with large constants, my compiler is actually taking an disproportionately large amount of time of doing the inverse of what the GHC simplifier did. I want to keep using the GHC simplifier, because it contains many optimisations that are usefull for my specific use-case. So my question is: how can I stop the GHC simplifier from breaking up large constants into smaller top-level bindings? As you could see from the example, this "breaking-apart-constants" is not due to the FullLaziness transform, as I explicitly disabled it. If this "breaking-apart-constants" part is not (currently) controllable by a flag, would it be possible to add such a flag? I'm happy to work on a patch myself if someone could tell where about in the simplifier I would have to make some changes. Thanks, Christiaan

2 2