Re: Should folds in containers package remain INLINE

On 5/3/12 7:46 PM, Johan Tibell wrote:

On Thu, May 3, 2012 at 4:31 PM, wren ng thornton 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