Could that specialization be accomplished today using eds reflection pkg? I guess not quite in terms of that pre apply pattern.
I'm not familiar with that package and couldn't find it on Hackage by a quick search. But I believe that it can only be done with compiler support, although with enough hackery you can probably get an ugly version of it using TH.
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.
Indeed. Specialisation is a really good way to get very fast code without making your executable size explode. I believe that support for more fine-grained specialisation should and will improve. I'm not sure how to make it more composable though.
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.