Ok cool. Sounds like we agree. <div>Luite and I talked about something similar a few months ago, I'll try to dig up my notes and maybe we can turn this into a ghc feature request or patch<span></span><br><br>On Saturday, April 25, 2015, Ertugrul Söylemez <<a href="mailto:ertesx@gmx.de">ertesx@gmx.de</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> are you sure you've evaluated how it interacts with this sort of<br>
> optimization? I think it actually gets you pretty far!<br>
<br>
Most of the magic occurs in reification.  The trouble is that it expects<br>
a polymorphic function of rank 2 with a nontrivial context (Reifies), a<br>
function that by construction cannot be specialised, unless you<br>
specialise the receiving function (reify) for every application case.<br>
The beauty of reflection is that it's free by virtue of sharing.<br>
Unfortunately sharing is the exact opposite of inlining.<br>
<br>
According to a benchmark I've done a few months ago it behaves exactly<br>
as if the reflected value was just a shared argument with no inlining<br>
performed; an expected and reasonable result.<br>
<br>
What I'm really after is a sort of controlled inlining.  That's pretty<br>
much what instance-based specialisation currently does for dictionaries.<br>
Technically a dictionary is just another argument, so there is no<br>
fundamental reason why we shouldn't have a more general specialiser.<br>
<br>
<br>
>> > Here yah go <a href="https://hackage.haskell.org/package/reflection" target="_blank">https://hackage.haskell.org/package/reflection</a><br>
>> > It exploits how dictionary passing works in a pretty robust way that<br>
>> > ghc is likely to at some point codify officially.<br>
>><br>
>> Oh, that one.  Of course I'm familiar with it, but it's less an<br>
>> optimisation than a clever way to implement implicit configurations.<br>
</blockquote></div>