15 Mar
2012
15 Mar
'12
4:22 p.m.
On 15 March 2012 15:47, Thomas Schilling
A few minor comments below.
Thanks for your documentation suggestions. I will certainly incorporate them into the final patch.
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?
To my mind, INLINEABLE really serves a different purpose than INLINE: it doesn't really force GHC to inline something, just expose the unfolding. We still need to force INLINE for SATed functions in order to achieve actual function specialisation. I think the other replies to the list elaborate on this point. Cheers, Max