Should folds in containers package remain INLINE

[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?

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.

-- 
Live well,
~wren