Could that specialization be accomplished today using eds reflection pkg? I guess not quite in terms of that pre apply pattern. <div><br></div><div>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. <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">> Likewise, to what extent aside from syntactic nicety does implicit<br>
> parameters and the punning extensions not suffice?<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 would<br>
like to have a version of my function `f` with a certain argument<br>
inlined.  Note that I don't want to inline `f` itself.  Rather I'd like<br>
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>