Yes, that. But do you really need such fancy logic in the test? Wouldn't something much simpler (like a type error) do the trick? Then you wouldn't have to deal with -ddump-parsed-ast.

Can you add a test case?

Although it's unfortunate to change benchmark source in general, I think it's pretty clearly justified this time.

• Add output

I believe this change needs a formal libraries list proposal.

Yup!

Yeah, that sounds reasonable. Not ideal, perhaps, but there's no obvious and easy way to make GHCi fail this without really reworking the test.

LGTM, if it validates.

• Add test

You state that this improves error messages, but you don't explain what happened before, what was wrong with it, what you're doing now, and what makes that better. Since this isn't entirely obvious, I suggest opening a Trac ticket.

• Pull out zapper; improve panic message

• Refactor

@simonpj, I didn't really want to use collectArgsTicks because it seems a bit expensive for the job. So for the moment I've written a function to just drop the arguments and ticks I need to make the comparison. Your other refactor request was definitely a major improvement. Thanks.

• Refactor

Remove likely-unnecessary bang pattern

Improve comment

I've opened D4796 to fix the problem in the simplifier.

• Add note.

Rebase

Rebase

Something isn't working. Also, it would be nice to have a test demonstrating that this sometimes does something useful.

In D4720#130537, @bgamari wrote:

What exactly is the problem here? Adding a test would help.

• Fix some more

Bleh! This part may take more community work. But I would leave it hidden
till we figure that out. The PR to process sounds like a good idea
regardless.

That's my suggestion for now, yes.

In D4692#129933, @adamse wrote:

@dfeuer, GHC.IntWord64 is from ghc-prim, that one should certainly not be removed from exposed-modules? (base imports it)

I mostly agree with this. However, I think there are some modules that simply shouldn't be exposed through Cabal at all, and revealing their Haddocks seems like a step in the wrong direction sending the message that some end users might want to use them. A notable example is GHC.IO.IOMode, whose entire contents are exported by System.IO. I'm pretty strongly opposed to unhiding this module, and generally in favor of removing it from the Exposed-modules section.

The proposal was rejected by the committee, so this will not be merged.

There are several things that don't fuse here. I'm not sure why as yet, but the unfoldings seem to get optimized too much. I think we can address that separately.

I don't see how perf.haskell.org will help you here. It just counts
instructions, so it's not going to tell you anything about the cache
effects you're after.

In D4679#129439, @AndreasK wrote:

Have you tested the performance implications?
I remember some programs in nofib actually getting slower with larger allocation sizes.

So it doesn't seem obvious to me that having the allocation area match a cache size would be better in general.

• Update notes
• Adjust test output

@bgamari, is it better now? Is the remark about threads at the end correct?

• Respond to Ben's comments

Remove unused imports

Yes.

If the performance difference is negligible compared to additions then there's no point. But remember that we don't need to use the same functions to define the instances for Float and Double. OTOH, I really wish these instances didn't even exist, so I shouldn't care of they're fast!

Something else to try: do different things depending on the magnitude of the arguments. If additions are substantially faster, then we'd prefer to use them when they don't lose too much precision. Can we get a conservative estimate of that for cheap? I conjecture that we can, especially if the step is an exact integer.

Unskip CI

Oh blast.... This thing skips CI, and I just changed code. Hrmmmmm....

• Change arity info for absentError and address Simon's other comments.

Good enough for me!

It looks like the remaining test suite failures are unrelated.

• Wall noise

• Add import of GHC.Num. This is okay because we already depend on GHC.List, which depends on GHC.Num.

Just a couple little things.

• Add instances for WrappedArrow

• Use the Monad and MonadPlus instances

• Missed a test

@RyanGlScott, I think I've handled your concerns.

• Document WrappedMonad

• Fixups

• Fix changelog

• Take care of <* as well