- ghc-devs - Haskell.org

Unicode, strings, and Show
by Manuel M T Chakravarty 31 Mar '16

31 Mar '16

Why are we doing this? GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help Prelude> "文字" "\25991\23383" Prelude> After all, we don’t print ’a’ as ’\97’. Manuel

7 12

GHC HEAD compile failure at ghctags: "missing: Cabal >=1.25 && <1.27"
by Conal Elliott 30 Mar '16

30 Mar '16

I'm trying to recompile GHC (via GHC 7.10.3) from freshly git-pulled HEAD, and "make" keeps dying at ghctags: Configuring ghctags-0.1... ghc-cabal: At least the following dependencies are missing: Cabal >=1.25 && <1.27 According to ghc-pkg I have Cabal 1.25.0.0 (compiled from a freshly git-pulled git clone). Any ideas what's going on and how I can fix it? Thanks. - Conal

2 2

singletons stuff in GHC.Generics?
by Carter Schonwald 30 Mar '16

30 Mar '16

Hey All, i just noticed that theres some Singletons code in the GHC.Generics module thats defined but not exported, whats the context on that? https://ghc.haskell.org/trac/ghc/ticket/11775#ticket is the ticket i created to track / ask for clarificaiton:) _Carter

2 2

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

29 Mar '16

Simon, did you meant P2? (Since you can't write instance (k ~ *) => Functor (P1 (a :: k)), as that's ill-kinded). Something like this? data P2 k (a :: k) = MkP2 instance (k ~ *) => Functor (P2 k) That's an interesting idea. Be aware that you actually can't compile that code at the moment, since GHC complains: * Expected kind ‘* -> *’, but ‘P2 k’ has kind ‘k -> *’ * In the first argument of ‘Functor’, namely ‘P2 k’ In the instance declaration for ‘Functor (P2 k)’ I hope this is a bug and not a fundamental limitation. There's another wrinkle in the design we must consider. Not only can datatypes have dependent type parameters, but so can typeclasses themselves. Consider: {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeInType #-} module Cat where import Data.Kind class Cat k (cat :: k -> k -> *) where catId :: cat a a catComp :: cat b c -> cat a b -> cat a c instance Cat * (->) where catId = id catComp = (.) newtype Fun a b = Fun (a -> b) deriving (Cat k) I was surprised to find out that this code currently compiles without issue on GHC 8.0, even though we're deriving (Cat k) instead of (Cat *). This is an effect of the way GHC currently handles deriving clauses, since it unifies the kind of the datatype and typeclass beforehand (therefore, it silently gets unified to Cat * before generating the instance). [1] Is this correct? It definitely feels a bit off. We currently allow this (see Trac #8865 [2]): newtype T a b = MkT (Either a b) deriving ( Category ) Even though Category :: k -> k -> * (i.e., we silently unify k with *). The difference here, as is the difference between P1 and P2 in Simon's email, is that k is not visible, so it's out-of-sight and out-of-mind. When k is visible, as in Cat, when now must be conscious of how it's used in a deriving clause. The Cat code is lying in the sense that we aren't deriving an instance that begins with (Cat k), but rather: instance Cat * Fun where ... Using Simon's advice, we could just as well generate: instance (k ~ *) => Cat k Fun where ... (Again, this doesn't currently compile on 8.0. I really hope that's just a bug.) So I'm starting to lean towards Simon's proposal. That is, we freely unify non-visible type parameters when deriving, but if a type parameter is visible, then we generate equality constraints instead of unifying it. Ryan S. ----- [1] http://git.haskell.org/ghc.git/blob/b0ab8db61568305f50947058fc5573e2382c84e… [2] https://ghc.haskell.org/trac/ghc/ticket/8865

3 3

GHC 8.0.1 release plan
by Ben Gamari 29 Mar '16

29 Mar '16

Hello GHCers, After numerous delays, I think we may finally be converging on a (hopefully final) 8.0.1 release candidate. Thanks to the tireless efforts of Richard Eisenberg, Simon PJ, and many others almost all of the release blocking tickets [1] have now been resolved. There are a few patches currently waiting for review that should hopefully be mergeable within the next few days. After these last patches have been merged I'll proceed in cutting the source distribution for GHC 8.0.1 release candidate 3. This release candidate will be made available immediately, although, in accordance with our new release policy [2], binary distributions won't be available until seven days later. Release candidate 3 will hopefully be the final release candidate for 8.0.1; the final 8.0.1 release will, with luck, be released in mid-April. This has indeed been a rather peculiar release and we hope that we'll be able to stick to a more consistent schedule for future releases. After the 8.0.1 release we'll need to discuss how we'd like to set the timeline for 8.2, our next major release. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1#Ticketsslatedfor8.0.1

2 2

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