--- Sebastian Sylvan
Some of the problems seem to be heavily geared towards an imperative *implementation*, meaning that a Haskell version is hardly idiomatic Haskell (and as such I , and I suspect otehrs, really have no inclination to work on it).
Take the fannuch benchmark for instance. Part of it is to generate input data (all permutations of a sequence). It would be better to not require the program to print out the first 30 lists from the input data, since that
additional (completely unneeded) restrictions on how to implement the program (and leads to an unnecessarily ugly implementation if you generate
I agree that several benchmarks suffer from this problem, but we have been trying to change this where possible. places the input in
a non-imperative fashion).
I must disagree. We based this benchmark on a very standard benchmark studied by Lisp implementors (and others, see e.g., http://citeseer.ist.psu.edu/315141.html)in an effort to address the problems of the original array access benchmark (which was extremely imperative in nature). I don't think asking Haskell to handle this simple program is unfair; Ken Anderson and others dealt with this for Lisp many years ago.
I assume it's no coincidence that this sequence exactly matches the "straightforward" way to generate permutations in C.
I should also note that I don't think these benchmarks mean anything at all. It would be better to test, say,
But I think Haskell may face real-world cases where data must be produced in some known order. For Haskell to be a contender in "real world" use, it sometimes has to confront ugly requirements. the best
possible solutions for some of the ICFP programming contests, for example. They say a lot more about real-world speed.
Agreed. However, it's a lot easier to get volunteers to implement small benchmarks (therefore, providing the ability to compare many languages) rather than large ICFP entries. -Brent