Unexpected list non-fusion

[wren ng thornton]

On 1/15/12 10:02 AM, Jan-Willem Maessen wrote:
> On Sat, Jan 14, 2012 at 10:48 PM, wren ng thornton<wren at freegeek.org>
> 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