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
