On Thu, Mar 15, 2012 at 8:47 AM, Thomas Schilling
This is a rather useful function, and if we define it in SATed style and with an INLINE pragma (as in my attached patch), GHC can generate really good code for it at use sites.
I think we're moving away from INLINE in favour of INLIN[E]ABLE. In this case it seems fine since it's just building a closure + tailcalling which probably would get optimised away. Still, would using INLINEABLE have a drawback in this case?
We've moved to INLINABLE for non-higher order functions with type class constraints. GHC does a great job with those (specializing them at the call site.) For HOF that call the higher order argument e.g. O(n) times, INLINE still works better. It removes both allocation of the closure and O(n) indirect calls. -- Johan