<div dir="ltr">are you sure you've evaluated how it interacts with this sort of optimization? I think it actually gets you pretty far!</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Apr 25, 2015 at 4:06 PM, Ertugrul Söylemez <span dir="ltr"><<a href="mailto:ertesx@gmx.de" target="_blank">ertesx@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> 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>
</span>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>
<div class="HOEnZb"><div class="h5"><br>
<br>
>> > 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>
>><br>
</div></div></blockquote></div><br></div>