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
