How many HOFs in Phobos?

[Daniel Gibson]

Am 01.02.2011 22:30, schrieb Andrei Alexandrescu:
> On 2/1/11 2:58 PM, Daniel Gibson wrote:
>> Am 01.02.2011 21:53, schrieb Jonathan M Davis:
>>> 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
>>
>> Well, he didn't want the slow Levenshtein implementation in Phobos (if I
>> understood correctly), but more higher order functions like fold*. These are not
>> inherently slow and are most probably useful to implement fast functions as
>> well ;)
> 
> The fact that foldl and foldr are only one letter apart is a design mistake.
> They have very different behavior, yet many functional programmers consider them
> largely interchangeable and are genuinely surprised when they hear the relative
> tradeoffs.
> 
> std.algorithm.reduce implements foldl, as it should. Simulating foldr on
> bidirectional ranges is as easy as reduce(retro(range)). Defining Haskell-style
> foldr on forward ranges would be difficult because it needs lazy evaluation
> through and through, and is at danger because people may use it naively.
> 
> For more info see the best answer at
> http://stackoverflow.com/questions/3429634/haskell-foldl-vs-foldr-question.
> 
> 
> Andrei

Thanks for the link :-)
I haven't used Haskell (or any other functional language) in a few years so I
forgot these details (to be honest, I don't think I understood the implications
explained in the stackoverflow post back then - I was happy when my Haskell
programs did what the exercises demanded).
I think that reduce as a non-lazy foldl is what people mostly need/want when
they use folding.
But I'm not sure if a lazy foldr (with whatever name to prevent people from
using it accidentally) may be useful.. I guess it's only useful when a list (or,
in D, range) is returned, i.e. the input list/range isn't really reduced like
when just calculating a sum or minimum or whatever.
I'm trying to think of use cases for this, but none (that aren't covered by map)
come to (my) mind - but this may be just because my brain isn't used to
functional programming anymore.

Cheers,
- Daniel