Should folds in containers package remain INLINE
wren ng thornton
wren at freegeek.org
Fri May 4 02:19:42 CEST 2012
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.
More information about the Libraries