[Haskell-cafe] Can Haskell outperform C++?

[Yves Parès]

> 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 at ertes.de>

> Ryan Newton <rrnewton at 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 at ertes.de>"
> FPrint: BD28 3E3F BE63 BADD 4157  9134 D56A 37FA E5DD 8D11
> Keysrv: hkp://subkeys.pgp.net/
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120521/a782cf64/attachment.htm>