
Not necessarily. For example the 'nub' function from Data.List could be much faster. Unfortunately this would also change its type. O(n²) complexity is really the best you can get with the Eq constraint.
Why not in that kind of cases provide a second function (named
differently), together with the original function, and specify they're
differences (i.e. wrt performances) in the doc?
It seems like a pretty quick and honest trade-off to me.
2012/5/21 Ertugrul Söylemez
Ryan Newton
wrote: I do think we have the opposite problem, however, in much Haskell code -- people are using the clean, obviously correct, but inefficient code even in standard library functions that really should be optimized like crazy!
Not necessarily. For example the 'nub' function from Data.List could be much faster. Unfortunately this would also change its type. O(n²) complexity is really the best you can get with the Eq constraint. You have to change to Ord for better performance.
In other words: Some optimizations change the semantics, and semantics is taken very seriously in Haskell, for which I'm grateful.
Greets, Ertugrul
-- Key-ID: E5DD8D11 "Ertugrul Soeylemez
" FPrint: BD28 3E3F BE63 BADD 4157 9134 D56A 37FA E5DD 8D11 Keysrv: hkp://subkeys.pgp.net/ _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe