Could that specialization be accomplished today using eds reflection pkg? I
guess not quite in terms of that pre apply pattern.
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.
On Saturday, April 25, 2015, Ertugrul Söylemez
Likewise, to what extent aside from syntactic nicety does implicit parameters and the punning extensions not suffice?
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.