Should folds in containers package remain INLINE
wren ng thornton
wren at freegeek.org
Fri May 4 01:31:30 CEST 2012
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
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?
I know one thing I run into a lot, especially with folds but also with
other generic functions, is that what I really want is type class
specialization. That is, at compile time inline the function enough to
make the type class parameters static so that the methods can be inlined
back into the generic function; and then at runtime do type-based
dispatch to the specialized versions just like if you were looking up
the instance record or doing SPECIALIZE lookup. The goal being to remove
the indirect calls in inner loops, but in a particularly restricted way
since instances are known at compile time and therefore code bloat will
be limited (unlike, say, function or record arguments).
Since that's one of the big goals that people use the INLINE hammer for,
I wonder if it would be sensible to have a pragma which specifically
offers those semantics. It doesn't quite solve the fold issue since many
folds use ad-hoc arguments, but it may help reduce code bloat elsewhere.
More information about the Libraries