proposal #3335: make some Applicative functions into method,
and split off Data.Functor
lemming at henning-thielemann.de
Wed Jul 8 10:15:44 EDT 2009
John Meacham wrote:
> On Sat, Jul 04, 2009 at 01:08:41AM +0200, Henning Thielemann wrote:
>> Ross Paterson schrieb:
>>> On Tue, Jun 30, 2009 at 01:37:05PM +0200, Henning Thielemann wrote:
>>>> This sounds like a rather ad-hoc extension of the already complicated
>>>> hierarchy of those category classes. Are there particular examples where
>>>> the specialisation is needed and where it cannot be done by optimizer
>>> Here's one for (<$). In Data.Sequence, I could define
>>> x <$ s = replicate (size s) x
>>> (using Louis Wasserman's replicate), which would take O(log n) time and
>>> space, a big improvement over the O(n) version using const and fmap.
>> Would it be reasonable to let the optimizer replace (x <$ s) by
>> (replicate (size s) x) via RULES?
> I don't like using RULES for optimizations that actually change the
> computational or space complexity of code.
It was said, that the new methods should equal the default definitions,
that is, they cannot be "optimized too much", e.g. the specialized
definitions are not allow to produce something defined where the default
definition is undefined. That's the situation where RULES are made for.
It's sad that application of RULES is so unreliable and maybe that
should be seriously improved. However, when doing optimization via type
class methods I see the danger that after splitting all standard type
classes down to one method per class in the past years we will see
another flood of extending the type class by specialized functions,
maybe followed by new splits. Maybe such a development is a good thing,
but then again, we still have no good tools to keep in sync with all
More information about the Libraries