Here yah go <a href="https://hackage.haskell.org/package/reflection">https://hackage.haskell.org/package/reflection</a><div>It exploits how dictionary passing works in a pretty robust way that ghc is likely to at some point codify officially. <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">> Could that specialization be accomplished today using eds reflection<br>
> pkg? I guess not quite in terms of that pre apply pattern.<br>
<br>
I'm not familiar with that package and couldn't find it on Hackage by a<br>
quick search.  But I believe that it can only be done with compiler<br>
support, although with enough hackery you can probably get an ugly<br>
version of it using TH.<br>
<br>
<br>
> This is interesting.  And it's a good example of a larger problem of<br>
> not enough support for composable specialization with good sharing<br>
> across the use sites that doesn't require egregious Inlining.  At<br>
> least for code that isn't Type class driven.<br>
<br>
Indeed.  Specialisation is a really good way to get very fast code<br>
without making your executable size explode.  I believe that support for<br>
more fine-grained specialisation should and will improve.  I'm not sure<br>
how to make it more composable though.<br>
<br>
<br>
>> At the definition and instantiation sites I mostly miss defaults.  At<br>
>> the application sites I would love to have specialisation for certain<br>
>> arguments.  For example I would like to be able to tell GHC that I<br>
>> would like to have a version of my function `f` with a certain<br>
>> argument inlined.  Note that I don't want to inline `f` itself.<br>
>> Rather I'd like to preapply certain arguments:<br>
>><br>
>>     f :: X -> Y -> Z<br>
>><br>
>>     {-# SPECIALISE f SomeX #-}<br>
>>     {-# SPECIALISE f SomeOtherX #-}<br>
>><br>
>> This would generate two specialised versions of `f` with exactly the<br>
>> given arguments inlined.  That way I can get a very efficient `f`<br>
>> without having to inline it at the application sites.  And as long as<br>
>> `f` is INLINABLE I can put those pragmas pretty much everywhere.  I<br>
>> believe this is exactly what happens for type class dictionaries.<br>
>><br>
>> This can (and probably should) be a separate feature though.  For some<br>
>> of my applications I need to inline a huge chunk of code multiple times<br>
>> to compensate for the lack of this feature.<br>
</blockquote></div>