Re: Unicode, strings, and Show

There was recently a discussion about it, search for subject "Can we improve Show instance for non-ascii charcters?" You can read for yourself but my impression was that people were generally favorable, but had some backward compatibility worries, and came up with some workarounds, but no one

Unicode, strings, and Show

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 ___ ghc-devs mailing list ghc-devs@haskell.org

Re: Initial compile time benchmarks

This ticket may be of interest: https://ghc.haskell.org/trac/ghc/ticket/9630 Deriving costs a lot and we just need someone to figure out what's going on. Edward Excerpts from Michael Sloan's message of 2016-03-29 15:23:50 -0700: > Great! Thanks for y'all putting effort towards performance. It

Re: Initial compile time benchmarks

Great! Thanks for y'all putting effort towards performance. It really is crucial for developer productivity. In the particular case of haskell-src-exts, I found that removing many of the more complicated typeclasses from deriving (Data, Generics, etc) brought the compilation time way down. IIRC

Re: Initial compile time benchmarks

Very cool! It would be nice to add build flags to the table (or at least optimization levels) as these probably differ across packages, and will certainly impact the numbers. I'd also be really interested to see a comparison of the timing data for -O0 and -O. I think the biggest impact for

Initial compile time benchmarks

Hi all, Using Ben's timing patch [^1], Cabal, and a Haskell program to parse generated logs [^2], I generated some tables that show compile times of modules in hxt, haskell-src-exts, lens, and all of their dependencies:

Re: instantiating visible parameters in when deriving instances

On Mar 29, 2016, at 3:58 PM, Ryan Scott wrote: > I hope this is a bug and not a fundamental limitation. As I posted in the ticket, this is a somewhat fundamental limitation. I qualify by "somewhat" because it's a consequence of a design choice, but reversing the

Re: GHC 8.0.1 release plan

Hello all, I just wanted to follow up on this. Yesterday, Ben and I spent some time and went over the current bug list[1]. If you saw that email yesterday - please refresh that page, we've trimmed the hedges a little bit. Please note that, barring any huge bugs in 8.0.1-rc3, we really aren't

Re: instantiating visible parameters in when deriving instances

> Why should it make a difference whether it's visible or not. Can't we behave > the same for both? Oops, I made the wrong distinction. I should have said: we freely unify eta-reduced type parameters when deriving, but if a type parameter isn't eta-reduced, then we generate equality constraints

RE: instantiating visible parameters in when deriving instances

| 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. Why should it make a difference whether it's visible or not. Can't

Re: More Higher-Kinded Typeclass Instances

Yeah, that is a lot of instances (especially all 62 types of tuples). I think you're right that it makes more sense to do this with an extension to the deriving mechanism, especially since even if I wrote them now, it would probably make sense to redo them with a deriving clause later. At the

Re: instantiating visible parameters in when deriving instances

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

Re: More Higher-Kinded Typeclass Instances

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

RE: instantiating visible parameters in when deriving instances

Just to be clear to everyone else, we are discussing data P1 (a :: k) = MkP1 deriving Functor data P2 k (a :: k) = MkP2 deriving Functor Here P2 has an explicit kind arg, which must appear in any use of P2; thus f :: P2 * Int -> Bool Now the question is: what derived instances do we

RE: possible tuple elimination optimization?

Yes: see https://ghc.haskell.org/trac/ghc/wiki/NestedCPR Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Dan Doel | Sent: 26 March 2016 20:41 | To: George Colpitts | Cc: ghc-devs@haskell.org | Subject: Re: