proposal #3335: make some Applicative functions into method, and split off Data.Functor

[Henning Thielemann]

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  
>>>> rules?
>>> 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 
these modifications.