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

Max Bolingbroke wrote:

On 15 February 2011 11:23, Roman Leshchinskiy 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. Roman