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>
>> 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.
More information about the Glasgow-haskell-users