ideas for compiler project

[Jerzy Karczmarczuk]

Simon Peyton-Jones:
 
> Lots of people have observed that Haskell might be a good "scripting
> language" for numerical computation.  In complicated numerical
> applications, the program may spend most of its time in (say) matrix
> multiply, which constitutes a tiny fraction of the code for the
> application. So write the bulk of the application in Haskell (where the
> logic is complex but the performance doesn't matter) and then link to a
> C or Fortran library to do the small part that is really compute
> intensive.
...
> You'd need to find a "real" application though. The classical "kernels"
> (matrix multiply, inversion etc) are precisely the things you may not
> want to do in Haskell.

That's it. With one "grain of salt". It happened to me that I wanted to
write some structurally trivial routines for matrix inversion, iterators for
ODEs, etc., but I wanted them *polymorphic*. (And, sometimes, lazy: 
manipulators of power series, asymptotic expansions, some automatic dif-
ferentiation stuff, etc.)

Then Haskell was a decent tool, and - as Björn Lisper remarks, the hindrance
was the lack of integrated tools. Writing a triple loop to invert a matrix
instead of having something like `recip` defined within the field of square
matrices, and implemented with some efficiency considerations in mind, is
a bit clumsy.

Björn quotes and comments:

> >The classical "kernels" [...] you may not want to do in Haskell.
> 
> With the current compiler technology for Haskell, one would add. I don't
> think it would be impossible to compile such Haskell programs into efficient
> code. Functional languages for matrix/array computing was a quite active
> research area 10-15 years ago, with efforts like Sisal and Id. These
> languages were strict and first order, but you can write such programs in
> Haskell. I think it would be possible to have a Haskell compiler that could
> manage a subset of Haskell matrix programs quite well. 

Steven Bevan wrote interesting numeric routines a long time ago.

Thorsten Zoerner wrote a Clean package Class with several Lin. Algebra
and some "slicing" utilities, which emulated the "vectorized" approach
of Matlab. This can be in its greater part translated into Haskell.

--- But, please, some criticisms of Matlab are weakly justified. BL says:

> Also, MATLAB is very ill-suited to
> expressing block-recursive matrix algorithms, which are becoming
> increasingly important in numerical computing. And, of course, there is no
> decent type system, no higher order functions, etc...

Block recursive Schemes in Matlab are easier than in C++. Implementing
pyramid algorithms is not difficult. Slicing, reshaping, cloning, etc.
of matrices are very powerful tools, but they are so imperative, that
it is not easy to see how to replace them with something "functionally
purified".

The Matlab type system is dynamic and "indecent", but you have objects
and inheritance, and you *HAVE* higher-order functions as well. All the
Matlab GUI tools, very powerful and reconfigurable are based on objects,
which accept callbacks as parameters. This is not so clean as we would
like to have, but pragmatically OK.

What bothers me a bit in our Haskell world is the fact that the efforts
are atomized. People work on GUIs, and don't care about drawing/painting
routines. Those who care, are often far away from the numerical world.
The numerically-oriented folk often disregard with a lot of desinvolture 
the attempts to put the Haskell numerical classes in an abstract algebraic
framework (really useful from the point of view of code reusing), etc.
I have the impression that this is changing, but slowly, while the scientific
computation/visualization world is marching very fast, not only in the
direction of very-fast-even-more-dirty routines, but also in the direction
of new conceptualization/representation models (like, e.g., "actors" in VTK).


Jerzy Karczmarczuk
Caen, France