15 Mar
2012
15 Mar
'12
4:02 p.m.
Hi,
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?
Reasonably small high order functions are marked INLINE, for example all folds, and I would consider traverseWithKey to be reasonably small. This allows to inline all calls to f in traverseWithKey, which can be a huge win (for example, if f only uses primops). Cheers, Milan