<div class="gmail_quote">On Fri, Sep 24, 2010 at 10:43 AM, Simon Peyton-Jones <span dir="ltr"><<a href="mailto:simonpj@microsoft.com">simonpj@microsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Specialisation<br>
<br>
One of the things that INLINABLE gives is that client modules can now see the full code for a function, even if it's recursive. So it is now (at last) relatively straightforward to generate specialisations for INLINABE functions in client modules. Here's how it'll go.<br>
<br>
Currently the specialiser (it focuses only on *overloaded* functions)<br></blockquote><div><br>With inlining, we speedups for (parametric) polymorphic functions as well, some of it due to the unboxing. Perhaps we could extend the set of functions that are candidates for specialization. If it's hard to decide in general which functions might benefit from specialization we can introduce a SPECIALIZABLE pragma that *applies at all types*, that acts like an INLINABLE pragma but makes the function a candidate for specialization, even if it's not an *overloaded* function.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">I think I'll also arrange that you can give a SPECIALISE pragma in a client module:<br>
{-# SPECIALISE lookup :: Map Int a -> Int -> Maybe a #-}<br></blockquote><div><br>I don't know if I want to litter client modules with SPECIALIZE pragmas, I think they should go in the library and not at the call site. For example, in C++ you get client module specialization without any annotations at the call site. We should be able to get by without having to have the client module care about these things.<br>
</div></div><br><br><br>Cheers,<br>Johan<br><br>