[Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results

Ronny Wichers Schreur ronny at cs.ru.nl
Thu Oct 7 09:34:37 EDT 2004

Andre Pang writes (in the Haskell cafe):

> The executive summary of my thoughts is that it seems to be 
> entirely possible to optimise Haskell to be competitive with 
> other, more performance-focused languages, but it's hard...

and from his blog:

> if you need speed, you can get it in Clean much more easily
> in than Haskell.

Perhaps Clean gives your more fine-grained control over the
memory and execution behaviour of your program, but this is
normally at the expense of clarity and elegance of your program.

This is where I think we (FP-ers) stand: We can write elegant
programs and we can write efficient programs, but combining
these two aspects is still difficult. The Haskell and Clean
entries in the Language Shootout clearly demonstrate this.

Here are some ideas to better combine elegance and efficiency

    - decouple data and functions
      It's often easy to make choices in the data structures
      with an eye to efficiency, for example sometimes it's
      better to unbox elements (faster access), sometimes it's
      better to share the elements (use less memory). The
      programmer should be able to make these decisions without
      changing the functions that use the data structure.
      Overloading can help, but perhaps a good implementation
      of views will improve it further.
    - more compiler optimisations
      Preferably the optimisations should be reasonably predictable
      for the programmer.
    - programmer guided transformations, optimisations
      I don't think we'll ever reach the state where compiler
      optimisations can completely bridge the gap between
      elegance and efficiency. I don't mind giving it
      some help, but I'd like to keep my original program.
      For example, tell the compiler to unfold a function once,
      so that the function is strict in more arguments in the

> [In Clean] you can, for example, make an unboxed, strict array
> just by writing [# 1, 2, 3 !] rather than [1, 2, 3]

I call [# 1, 2, 3 !] a tail-strict list with unboxed elements
(it doesn't have constant time access).


Ronny Wichers Schreur

More information about the Haskell-Cafe mailing list