Hey! Good for you John!! We seem to hear an awlfull lot about
what Haskell does not(or should) do. Never too much about
what does or can be made to do.
Ed
John O'Donnell wrote:
> There's another way to look at the role of Haskell in scientific computing.
> All the discussion so far is assuming that (1) you write your program in
> Haskell, (2) you run it through a compiler, (3) you compare the speed with
> Fortran, (4) you sigh and give up...
>
> In this picture, Haskell is being used to express the algorithm at just one
> level of abstraction. Now, Fortran is a very limited language, and it's only
> capable of expressing one level of abstraction. But Haskell does *not*
> have that limitation!
>
> So there is another way to use functional languages: they can help you to
> express your algorithm cleanly and simply, and they can also help you in
> deriving a more efficient low-level version via program transformation. If
> you like, it's possible to transform the program all the way down to C or
> Fortran, and at that point you don't need a Haskell compiler or graph
> reduction at all - you just use the Fortran or C compiler.
>
> Naturally, this transformational approach doesn't help if you start out
> thinking of the algorithm in a low level, first order style with lots of
> imperative iterations over arrays. In such cases one might as well just write
> the program in Fortran to start with.
>
> However, there are some algorithms that are very difficult to write in Fortran
> or C, but which can be expressed much more clearly and simply in a functional
> style. (A good example of this is the hierarchical radiosit algorithm.) You
> can write a high level executable specification, using Haskell and ghc; if the
> performance is inadequate, then you can transform the program to a lower
> level. The crucial point here is that the transformations are not aimed at
> getting rid of inefficiencies caused by graph reduction or the like; the
> transformations are aimed at making the algorithm fit better onto the
> underlying architecture.
>
> One apparent problem with the transformational approach is that it's a lot of
> work. Isn't it easier just to write your program once, in a language that
> supports only one level of abstraction, and compile it? I think this is a
> valid criticism (after all, *I* am the one raising it!) but there are two
> counterarguments:
>
> -- some of the transformation steps required are straightforward and
> boring, but there may be the possibility of automating these. After
> all, even the ghc compiler is a transformational system `under
> the hood'. Full transformational automation has not been achieved
> yet, but work is underway.
>
> -- For some algorithms, insight is needed to transform down to a
> low level efficient implementation: "Eureka steps". It is
> unrealistic to expect a compiler to find Eureka steps, but the
> transformational approach may make it possible to automate the
> boring steps while allowing the programmer to insert clever
> insights. You can't do this with compilers, and you can't do
> it with languages that can express algorithms only at one level
> of abstraction.
>
> John O'Donnell
