How many HOFs in Phobos?

[Andrei Alexandrescu]

On 2/1/11 2:53 PM, Jonathan M Davis wrote:
> On Tuesday 01 February 2011 12:27:32 bearophile wrote:
>> Walter:
>>> It's exponentially bad performance makes it short, not useful.
>>
>> A program with high complexity is not a problem if you run it only on few
>> very short examples. There is a place to care for performance (like when
>> you design a function for Phobos) and there are places where you care for
>> other things.
>>
>> I suggest top stop focusing only on a fault of a program that was not
>> designed for performance (and if you want to start looking at the numerous
>> good things present in Haskell. Haskell language and its implementation
>> contains tens of good ideas).
>
> The issue is that if you want something in Phobos, it _does_ need to be designed
> with performance in mind. Anything which isn't efficient needs to have a very good
> reason for its existence which balances out its lack of efficiency. If the Haskell
> implementation isn't performant enough, then it doesn't cut it for Phobos, even
> if it's a good fit for Haskell.
>
> - Jonathan M Davis

I think this is a bit much, though probably a good principle to live 
into. For example Phobos does include linear search routines that are 
"inefficient" - i.e. O(m * n). It also has many abstractions that are 
arguably not as efficient as they could be, either at high level, low 
level, or both. But something like foldr that uses head recursion would 
be indeed rather dangerous to include.

Andrei