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