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

[Max Bolingbroke]

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.

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). This differs from the current story in that with
the present setup you can write the INLINE and default method directly
in the class definition, and then GHC does not need to inline the
small RHS of the default to get a chance to apply its inlining
heuristics on the "actual" default method.

However, given that these small RHSes *should* be inlined eagerly and
ubiquitously, there shouldn't be a detectable difference writing
default methods directly and the proposed pattern for adding INLINE
pragmas to default methods.

> Also, what if I write:
>
> class MyClass a where
>  foo :: a -> a
>  foo x = default_foo x
>
> I assume this wouldn't guarantee inlining?

I don't know about any guarantee -- again personally I would only hope
the inlining would only occur should GHC decide it is worth it -- but
this still looks like it should be OK under the no-size-increase
inlining heuristic. I think the simplifier will probably avoid
actually inlining unless foo is applied to at least 1 arg to avoid
increasing allocation, but any interesting use site will meet that
condition.

I do not really know what the simplifier does in enough detail to know
exactly what will happen here, though. This is just an educated guess
as to what will happen, which makes me think that my proposed pattern
is OK.

Cheers,
Max