Summary of containers patches

[Johan Tibell]

On Fri, Sep 24, 2010 at 10:43 AM, Simon Peyton-Jones
<simonpj at microsoft.com>wrote:

> Specialisation
>
> 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.
>
> Currently the specialiser (it focuses only on *overloaded* functions)
>

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.

I think I'll also arrange that you can give a SPECIALISE pragma in a client
> module:
> {-# SPECIALISE lookup :: Map Int a -> Int -> Maybe a #-}
>

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.



Cheers,
Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20100924/5f2b87a0/attachment.html