Unexpected list non-fusion

wren ng thornton wren at freegeek.org
Mon Jan 16 00:15:50 CET 2012

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,

More information about the Glasgow-haskell-users mailing list