Should folds in containers package remain INLINE

[wren ng thornton]

On 5/3/12 7:46 PM, Johan Tibell wrote:
> On Thu, May 3, 2012 at 4:31 PM, wren ng thornton<wren at freegeek.org>  wrote:
>> 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.

Ah, ISTR that the goal was to make things look cheap ---to remove 
certain conflicts that had been necessitating INLINE--- without actually 
'forcing' the inlining to happen. (Yes, I know INLINE doesn't actually 
guarantee inlining will happen.) So it's just making it possible to 
inline, rather than actually affecting any decisions about inlining then?


> 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.

So INLINABLE does do type class specialization. Excellent.

-- 
Live well,
~wren