- ghc-devs - Haskell.org

Harbourmaster is still not building diffs
by Matthew Pickering 13 Aug '16

13 Aug '16

Since a couple of months ago, harbourmaster no longer builds diffs. This is quite a large barrier to entry for new contributors as running ./validate takes a long time. It seems to be a very low priority issue to get it back working. Are there plans to get harbourmaster to build diffs again? Matt

2 2

enumFromThenTo for Doubles
by Andrew Farmer 11 Aug '16

11 Aug '16

Noticed this today: ghci> let xs = [0.0,0.1 .. 86400.0] in maximum xs 86400.0000005062 enumFromThenTo is implemented by numericEnumFromThenTo: https://github.com/ghc/ghc/blob/a90085bd45239fffd65c01c24752a9bbcef346f1/li… Which probably accumulates error in numericEnumFromThen with the (m+m-n): numericEnumFromThen n m = n `seq` m `seq` (n : numericEnumFromThen m (m+m-n)) Why not define numericEnumFromThen as: numericEnumFromThen n m = let d = m - n in d `seq` go d n where go delta x = x `seq` (x : go delta (x + delta)) (or with BangPatterns) numericEnumFromThen n m = go (m - n) n where go !delta !x = x : go delta (x + delta) Seems like we'd save a lot of subtractions by using the worker function.

4 4

Noticing how the Rust team is improving compiler errors
by Christopher Allen 11 Aug '16

11 Aug '16

https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-come.html I'd particularly note that their compiler errors were dramatically better to begin with, now they're doing this. Thought the list would be interested in this. --- Chris

1 0

[ANNOUNCE] Hac φ: a Haskell Exchange in Philadelphia, Oct 21–23
by Kenny Foner 10 Aug '16

10 Aug '16

Hello Haskellers, Hac Phi, a yearly weekend of Haskell in Philadelphia, will take place Oct. 21–23, 2016, at the University of Pennsylvania. Hac Phi is a gathering of hackers and Haskell enthusiasts. Come bring a project you’re working on or offer to help someone else on a project of theirs. Come give a talk if you’ve got something to share. Come to learn something new. What do we mean by a “Haskell Exchange”? Less pressurized than a hackathon, more informal than a conference, bigger than a meetup – Hac Phi is a weekend where academics, professionals, and hobbyists can all meet, mingle, hack on each others’ projects, and generally have a good time. (And it’s not to be confused with the Haskell eXchange, an entirely different event.) All the details are on the wiki page <https://wiki.haskell.org/Hac_%CF%86>; please register online <https://docs.google.com/forms/d/e/1FAIpQLSd4i-tURfHBqmwxqOqozkjoyHfmMUl99Ax…> if you’re coming. We hope to see you there! —The Hac φ team Antal Spector-Zabusky Kenny Foner

1 0

Improving cost center reports to show residency?
by Ömer Sinan Ağacan 08 Aug '16

08 Aug '16

One thing that we can't currently see in cost center reports is the residency and because of that cost centers can't be used for fixing memory leaks or reducing max. memory residency. For example, I can have a function that returns an `Int` but allocates lots of intermediate data on the way. In the reports I see this function as allocates a lot, but it has no effect on my program's residency (especially if it runs fast). So I'm thinking of somehow using cost centers for reasoning about memory residency. One idea is to print a summary after every major GC, by doing another pass on the whole heap and recording attributions. This can be used for plotting live data of cost centers over time. (like hp2ps but for cost centers) Another idea is to add "residency" column in the profiling reports. Not sure how to update this column in runtime though. The main use case for me is fixing T1969, but of course this is a very general solution. Does anyone have any other ideas?

2 1

Can we offer ~ without GADTs or type families?
by David Feuer 06 Aug '16

06 Aug '16

It seems to me that equality constraints could potentially be supported by an implementation with neither GADTs nor type families. Type families don't really seem to have much to do with it, and GADTs are strictly heavier (GADTs ~= ExistentialQuantification + TypeEquality). Could we get a separate LANGUAGE pragma just for equality constraints?

3 2

Re: [commit: ghc] master: Replace some `length . filter` with `count` (02614fd)
by Joachim Breitner 06 Aug '16

06 Aug '16

Hi, Am Freitag, den 05.08.2016, 22:41 +0000 schrieb git(a)git.haskell.org: > commit 02614fd61f57b599c5e4fd5e85f00a4e1ce37bc7 > Author: Ömer Sinan Ağacan <omeragacan(a)gmail.com> > Date: Fri Aug 5 20:58:02 2016 +0000 > > Replace some `length . filter` with `count` Well intended! I wouldn’t be surprised if this is actually making the code worse, considering that "count" is implemented in the “wrong”, stackeating way (whereas lenght . filter could, thanks to list fusion, produce the desired code) count :: (a -> Bool) -> [a] -> Int count _ [] = 0 count p (x:xs) | p x = 1 + count p xs | otherwise = count p xs I would say that the regression reported by https://perf.haskell.org/ghc/#revision/02614fd61f57b599c5e4fd5e85f00a4e1ce3… confirms this, but T6048 is simply unreliable. So practically, it does not seem to matter either way. I’ll change the implementation of count. (Although even then it is not clear that the change is a win, as "length . filter" might fuse with the producer, whereas "count" without a lot of extra hassle will not.) Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

1 0

Re: Can we offer ~ without GADTs or type families?
by Ryan Scott 05 Aug '16

05 Aug '16

Hi David, > Could we get a separate LANGUAGE pragma just for equality constraints? I think we should, and I don't think we'd even need to introduce a new pragma, since there's already a perfectly good one: -XTypeOperators! After all, there's nothing really that special about (~) other than some typechecking details. A fix to Trac #9194 [1] would give us this. Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/9194

2 2

Deriving tweaking
by David Feuer 05 Aug '16

05 Aug '16

I know there's been some discussion about letting users select the deriving mechanism they want, but I'd like to propose a separate tweak to the defaults. Specifically, it's annoying to have to use three pragmas to let me write newtype Foo f a = Foo (f a) deriving (Functor, Foldable, Traversable) data Bar f a = Bar (f a) deriving (Functor, Foldable, Traversable) and more annoying still that I'll end up with Foldable and Functor instances for Foo that may be much worse than GND-derived ones. The tweaks I'm after: 1. Prefer GND to the built-in derivations for Functor and Foldable, and probably also Eq and Ord. 2. Make DeriveTraversable imply DeriveFunctor and DeriveFoldable.

2 2

Re: Deriving tweaking
by Ryan Scott 05 Aug '16

05 Aug '16

You're in luck, David, since both of your requests are currently things that GHC will do. Specifically, > 1. Prefer GND to the built-in derivations for Functor and Foldable, and probably also Eq and Ord. GHC will always derive Eq and Ord instances for newtypes using GND, and will prefer GND when deriving Functor and Foldable instances for newtypes when (1) the -XGeneralizedNewtypeDeriving extension is on, and (2) eta-reducing the type variable is allowed. See [1] for the full details on how GHC chooses when to pick GND behind the scenes. > 2. Make DeriveTraversable imply DeriveFunctor and DeriveFoldable. That's already the case, thanks to Trac #9069. [2] Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrategie… [2] https://ghc.haskell.org/trac/ghc/ticket/9069

1 0