Re: Unexpected list non-fusion

On 1/15/12 10:02 AM, Jan-Willem Maessen wrote:

On Sat, Jan 14, 2012 at 10:48 PM, wren ng thornton wrote:

...

On 12/12/11 3:37 PM, wren ng thornton wrote:

...

I've noticed that take and filter are good producers (and consumers) for list fusion, but takeWhile, drop, and dropWhile are not. Is there any reason for this discrepancy?

If not, would I need to go through the libraries@ process for fixing it, or should I just submit a patch?

In working on a patch to fix this I've come upon a question. The fusion rules for take seem a bit odd in that they translate the take into a foldr which produces (Int# -> b), instead of passing the Int# in directly and using foldr to produce the b.

Does anyone know why?

This is the "turn any list traversal into a foldr using a higher-order fold" trick.

I know _what_ it's doing, I'm more curious about why. From looking through the code there didn't appear to be any reason to prefer this higher-order version instead of the straight-forward version. I'm curious if there's some performance quirk that I should beware of... Oh, right. The cons of the list algebra isn't fixed throughout the recursion. Duh. Should've tried to see if it was even possible the easy way. -- Live well, ~wren