GHC 7.10 regression when using foldr
Edward Kmett
ekmett at gmail.com
Tue Jan 20 16:34:56 UTC 2015
On Tue, Jan 20, 2015 at 9:00 AM, Kim-Ee Yeoh <ky3 at atamo.com> wrote:
>
> There are few reports because the change hasn't affected the dark majority
> yet. RC builds are used by a tiny fraction. There's a long tail of users
> still on 7.6, 7.4, 7.2, and 6.x.
>
We've been actively testing since the first time we had a usable
implementation of both the Foldable/Traversable proposal and AMP. Very
large chunks of hackage have been built in house with hand-patched
upstreams to maximize how much of it we can build and we've been using that
to try to minimize impact. Herbert has been hard at work on this for six
months now.
It was known going in that there'd be some broken eggs, and that there'd be
a large number of details to figure out, so Simon formed the core libraries
committee in part to have someone responsible for making decisions around
situations like this.
Far and away the greatest contributing factor to build failures in 7.10 is
the AMP. More code is broken by the import of (<*>) in Applicative alone.
As in, going into the same release, the Foldable/Traversable changes barely
blip the build-failure radar, by a factor of 50 compared to AMP-induced
failures.
The whack-a-mole game needs only to be played once and the results shared
> among those relying on the abstractions. Was that route ever explored?
>
Yes. You could say that this is precisely what we've been doing since 2008.
We've had a dozen or so alternate preludes. Nobody wants the extra build
dependency or per module setup cost. We've had a proposal to eliminate the
Prelude entirely by Igloo, to make it so if you import Prelude.Foo you'd
get that Prelude and not the other. I also spent much of 2014 going around
to every Haskell meetup I could make it to around the world looking for
more direct feedback from folks. The list goes on of options that have been
put on the table.
It does nothing to stem the tide of users who reinvent these abstractions,
or who by dint of the undiscoverability of the current API never find out
about it. The classy-prelude for instance when it was first released didn't
know that there was any pre-existing relationship between virtually all the
combinators it offered and split things up into dozens of classes.
A separate Prelude doesn't address the fact that the limited versions of
these functions are re-exported over and over across dozens of other
modules within base and without.
To that end we had a proposal. It had the most feedback of any proposal
ever put forth on the libraries mailing list, but it went through with
something like 90% approval. I'm not one to speak of "mandates from the
people", but if anything ever came close, that sounds like one to me.
The FTP discussion needs to be re-opened. And it will be, eventually.
>
That statement needs some seriously sinister music. ;)
-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150120/4cf352c7/attachment.html>
More information about the Glasgow-haskell-users
mailing list