Bjorn Lisper <[EMAIL PROTECTED]> wrote,
> "D. Tweed" <[EMAIL PROTECTED]>:
> >I'm quite open to arguments that maybe you can't
> >make a functional language that's as nice as Haskell (features like lazy
> >evaluation, nice type classes, etc) that's also able to `really hammer
> >until it's totally flat' functional code that implements heavily numerical
> >algorithms. However I'd argue that this is still an area where a
> >functional language which was standard, widely used and compilable into
> >very very efficient code would be of great benefit to many people who work
> >on simulation, image processing problems, control systems, etc. (So I'm
> >happy for the Haskell people to say `We can't make
> >computation intensive programming better because it'd screw up stuff we do
> >well now' but not that `development time shrinkage compensates for
> >run-time growth'.)
>
> Sisal was an attempt to define precisely such a functional language. Of
> course, it is not nearly as "nice" as Haskell as regards features:
> restricted type system, call by value (except a particular nonstrict data
> type for streams), no higher order functions, no recursive array
> comprehensions, etc. These limitations were deliberate design decisions
> made to make the compilation to efficient code simpler. Sisal also has a
> rich set of array primitives and a loop-like notation which is syntactic
> sugar for tail-recursion (the latter making it possible to write
> surprisingly Fortran-like code in Sisal...). On a standard set of
> benchmarks, a couple of years back, Sisal obtained performance on par with
> the state-of-the-art parallelising/vectorising Fortran compilers of that
> time. There's a C.ACM paper on this, from -93 I think.
>
> Yet, Sisal never took off. As far as I know there is neither any development
> of the language nor on compilers now.
I would offer the following two reasons as contributing to
the lack of acceptance of Sisal:
* While Sisal is arguably nice than Fortran, it doesn't
really provide a new killer feature - rewriting all this
Fortran code, just for getting nice programs is maybe not
enough of an incentive.
* IIRC, Sisal squarely aimed vector computers, while current
parallel computer technology moves to distributed memory
machines build around scalar processors.
I won't claim that this is the whole story, but I believe
these are two important point
If you are interested in a project implementing a Nesl-like[1]
language that tries to avoid at least these two problems,
have a look at
http://www.score.is.tsukuba.ac.jp/~chak/nepal/
The killer feature is nested data parallelism, ie, you can
arbitrarily nest data parallel computations - try this in
Fortran! Concerning the second point, the compiler - while
portable - targets first of all distributed memory
machines. (Unfortunately, the compiler needs a lot more
work, before it is generally usable.)
You may also want to have a look at SAC:
http://www.informatik.uni-kiel.de/~sacbase/index.html
It comes with a C-like syntax, but is purely functional and
aims at exactly the kind of numerical applications for which
Fortran is used a lot - they use a lot of compiler
optimisations to generate efficient code.
So, the last word about using functional languages for
numerical applications is not yet spoken.
Cheers,
Manuel
PS: I am aware that there are many more approaches out there
that I could have mentioned here - I didn't do so,
because I am a _lazy_ functional programmer.
[1] Actually, the concept of nested data parallelism is from
Nesl, but otherwise the implemented language is a subset
of Haskell using easger evaluation.
