This is interesting. And it's a good example of a larger problem of not enough support for composable specialization with good sharing across the use sites that doesn't require egregious Inlining. At least for code that isn't Type class driven.

On Saturday, April 25, 2015, Ertugrul Söylemez <ertesx@gmx.de> wrote:

> Likewise, to what extent aside from syntactic nicety does implicit
> parameters and the punning extensions not suffice?

At the definition and instantiation sites I mostly miss defaults. At
the application sites I would love to have specialisation for certain
arguments. For example I would like to be able to tell GHC that I would
like to have a version of my function `f` with a certain argument
inlined. Note that I don't want to inline `f` itself. Rather I'd like
to preapply certain arguments:

f :: X -> Y -> Z

{-# SPECIALISE f SomeX #-}
{-# SPECIALISE f SomeOtherX #-}

This would generate two specialised versions of `f` with exactly the
given arguments inlined. That way I can get a very efficient `f`
without having to inline it at the application sites. And as long as
`f` is INLINABLE I can put those pragmas pretty much everywhere. I
believe this is exactly what happens for type class dictionaries.

This can (and probably should) be a separate feature though. For some
of my applications I need to inline a huge chunk of code multiple times
to compensate for the lack of this feature.