Should folds in containers package remain INLINE

[Johan Tibell]

On Thu, May 3, 2012 at 4:31 PM, wren ng thornton <wren at freegeek.org> wrote:
> On 5/2/12 7:16 AM, Simon Marlow wrote:
>>
>> I would like the folds to be INLINABLE. Rationale:
>>
>> - The 0.8% figure is really plucked out of thin air, it depends
>> entirely on how many times we call fold.
>>
>> - Getting a complete copy of fold each time you call it is overkill.
>>
>> - INLINABLE puts the user in control of the performance/size
>> tradeoff; with INLINE the user has no control, they always get
>> a copy (well, they could write a NOINLINE wrapper, but that's
>> horrible).
>
>
> What exactly are the semantics of INLINABLE again? I know it means that it's
> like a constructor in that it's considered cheap to reevaluate, but how does
> that play into the whole inlining/rules/fusion/cse infrastructure?

INLINABLE: make the core available in the .hi file so this function
*may* be inlined.
INLINE:: make the core available in the .hi file so this function
*may* be inlined, also try to inline the function.

So INLINABLE does make the function look any cheaper (i.e. not like a
constructor.) It just makes sure that the functions definition is
available when compiling other modules.

However, GHC also specializes (at the call site) functions with type
class arguments that are marked as INLINABLE (it might also specialize
such functions even without the INLINABLE.) The containers package
makes frequent use of INLINABLE for this reason.

-- Johan