> 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 <es@ertes.de>
Ryan Newton <rrnewton@gmail.com> 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 <es@ertes.de>"
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