
On 1/4/06, Brent Fulgham
--- Sebastian Sylvan
wrote: 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).
I agree that several benchmarks suffer from this problem, but we have been trying to change this where possible.
A good example of an unfair benchmark that Udo Stenzel noted over at the shootout haskell wiki is "sum-file". Here you specify that no line is ever more than 128 characters long. What's the purpose of doing that? Clearly it's to make life easier for C programmers, is it not? (do C programs never have to deal with the "real world" where such assumptions can't be made?). Furthermore an 128 digit number in base 10 would occupy 53 bytes, but the C (and most other) implementations assume that it will all fit within one machine word, which is obviously against the spec (the only thing the spec says about size of the numbers is that it's at most 127 digits, since one char is a newline, so the implementation must assume the worst about the size of the numbers to be compliant). This is a one-liner in idiomatic Haskell (getContents >>= print . sum . map read . lines), but since there are restrictions specifically tailored to make life easier for lower level languages, the Haskell submission must resort to all sorts of "hacks" to compete (to circumvent the high-level general tools available). Unfair! /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862