> 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 <[email protected]> > Ryan Newton <[email protected]> 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 <[email protected]>" > FPrint: BD28 3E3F BE63 BADD 4157 9134 D56A 37FA E5DD 8D11 > Keysrv: hkp://subkeys.pgp.net/ > > _______________________________________________ > Haskell-Cafe mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/haskell-cafe > >
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
