I don't know Haskell very well, but
Paul: "I'm not racist but . . ." :-)
even I can tell, looking at, for example, the N-body benchmark, that the Haskell code is probably not type-safe, and the tricks used in it would not be usable in a larger program (see below).
The task is essentially a pure computation: take a list of bodies having mass, position and velocity; apply Newton laws at discrete intervals for a large number of times; return new positions and velocities.
I could write a C++ procedure that performs this task and have some piece of mind regarding its type correctness, exception safety and functional purity: side effects would be local to the procedure, arguments passed as const or by value, the result returned by value, no type casts or new/delete operators used.
On the other hand, the Haskell code makes assumptions about the size of double-precision floats (obviously not type-safe). Further, the simulation is not a pure function.
It is often argued that one only needs these dirty tricks in the most time-consuming functions. However, if using imperative programming in these "inner loop" procedures places them in IO monad, the "outer loops" (the rest of the program - procedures that call it) will have to go there as well. This makes me doubt the Haskell approach to functional programming.
If anyone has a version of the N-body benchmark, where the simulation is a type-safe pure function, I would very much like to see and time it. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe