Crossposted to the SAC mailing list because I'm curious to learn whether
there is any chance to get the best of both worlds..
{-
Summary for the readers of sac-list: this is from a thread on the Haskell
mailing-list, discussing the old problem of whether functional language
implementations (here: for Haskell) will ever be efficient enough to
compete with C, etc. for computation intensive computations. After the
standard (?-) arguments, we have reached a point where the questions
seem to be:
- how efficient can computation intensive algorithms be implemented
in Haskell (with/without extensions, now/ever)?
- if the best efficiency for Haskell isn't good enough for a particular
application, do we need to go back to coding it in C/Fortran?
- Sisal, SAC, .. have efficiency as a major design goal, and claim
to be functional. How does this help the Haskell programmer, and why
can't we have everything?
-}
>Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> wrote:
>On Wed, Sep 22, 1999 at 09:44:34AM +0200, Bjorn Lisper wrote:
>> Sisal was an attempt to define precisely such a functional language.
>...
>> no higher order functions
>
>Uhh... have I misunderstood what functional programming is? Isn't
>higher-order function support a necessary part of every FP language?
Replace "necessary" with "useful", "attractive", "nice to have"..
Manuel did already mention SAC, which also does not (yet) have
higher-order functions. That doesn't mean that Sisal or SAC are not
functional languages.
Functional programming, i.e., programming with functions, is possible in
languages that do not support all features that have become common in
many functional languages. The better a language supports the subset of
features that you need, the better the language is suited for your
current problem.
>From the perspective of numerical programmers, you could also ask: Isn't
compilation of high-level array operations into efficient code a
necessary part of every useful (FP) language?
The idea behind languages such as Sisal or, more recently, SAC is to
start with a minimal subset of "functional" features and to focus on the
efficient implementation of such a "sub"-language. Once an efficient
implementation of the basic set of features is available, more and more
of the nice functional features can be added, provided they do not
compromise the efficiency of the base language.
This bottom-up approach to functional language design and implementation
was chosen for SAC exactly because of the difficulties of the standard,
top-down approach: If you start with the complete feature set of a
modern general-purpose functional language such as Haskell, it is very
hard to do the program analyses on which good optimizations are based.
Likewise, it is difficult to isolate the language subsets for which such
analyses would be possible.
The hope was that a bottom-up approach would deliver good performance
for a sub-language soon (see recent performance results for SAC), and
that the performance/expressiveness trade-offs for additional features
would be examined before these features are added to the language.
Languages such as Haskell and SAC show some of the variety of functional
language designs and implementations - currently, there is still a huge
gap: Haskell provides more of the general-purpose features, but lacks
implementations with good performance for numerical computations, while
SAC offers excellent performance on some numerical benchmarks, but lacks
many of the nice general-purpose features (it does offer nice
array-specific features, though). Other functional languages offer
compromises in between, whereas extensions to Haskell try to improve
performance without giving away expressiveness..
While we are waiting for this gap to close, it seems we have to choose
from the range of (functional) languages between the extremes to find the
best language for each problem.
Claus
PS. An interim workaround could be a way to call SAC from Haskell,
allowing computation- and array- intensive program parts to be
implemented in SAC, and the rest in Haskell.
Note that most SAC optimizations depend on the ability to do precise
static program analyses, and that many optimizations span blocks of
operations, so a SAC array library for Haskell would find it
difficult to achieve even some of the impressive performance of SAC
alone. Still, I am sure that the SAC and Haskell teams (and users)
would welcome anyone who would be willing to take up this particular
challenge!-)
