[Haskell-cafe] rewrite rules to specialize function according to type class?

Roman Leshchinskiy rl at cse.unsw.edu.au
Tue Feb 15 16:12:41 CET 2011

Max Bolingbroke wrote:
> On 15 February 2011 11:23, Roman Leshchinskiy <rl at cse.unsw.edu.au> wrote:
>> I wouldn't necessarily expect this to guarantee inlining for the same
>> reason that the following code doesn't guarantee that foo gets rewritten
>>  to <big>:
>> foo = bar
>> {-# INLINE bar #-}
>> bar = <big>
>> It might work with the current implementation (I'm not even sure if it
>> does) but it would always look dodgy to me.
> In this case there doesn't seem to be any point inlining anyway,
> because nothing is known about the context into which you are inlining.
> Nonetheless, what will happen (I think) is that any users of
> "foo" will get the definition of "foo" inlined (because that doesn't
> increase program size) so now they refer to "bar" instead. Now GHC can look
> at the use site of bar and the definition of bar and decide whether it is
> a good idea to inline.

Ah, but you assume that bar won't be inlined into foo first. Consider that
it is perfectly acceptable for GHC to generate this:

foo = <big>
{-# INLINE bar #-}
bar = <big>

We did ask to inline bar, after all.

> Basically, I expect the small RHS for the default in my class
> declaration to be inlined unconditionally, and then GHCs heuristics will
> determine how and when to inline the "actual" default definition (e.g.
> default_foo).

As soon as GHC generates a Core term for the RHS of the default method all
bets are off because it might inline default_foo into that term which
would make it too big to be inlined somewhere else. I thought you were
suggesting to treat "foo = default_foo" specially by not generating a
separate RHS for the default definition of foo and just rewriting it to
default_foo instead.

What it basically comes down to is a staging problem. You don't want
default_foo to be inlined into the RHS of foo before the latter is inlined
but the only way to achieve this is by marking foo as INLINE which is
precisely what you want to avoid.


More information about the Haskell-Cafe mailing list