On 22-Sep-1999, Claus Reinke <[EMAIL PROTECTED]> wrote:
> 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.
On a related note, we took the same kind of approach with Mercury:
we started with a basic set of features (a strict, strongly moded
strongly typed logic programming language) and developed an efficient
implementation of that minimal language, and since then we've been busy
adding support for additional features based on ideas from the
functional programming community (functions, higher-order functions,
optional dynamic typing, library support for lazy evaluation,
exception handling, typeclasses, existential types, ...),
the logic programming community (support for optional dynamic moding,
dynamic scheduling, constraint solvers, trailing, tabling, ...),
and elsewhere (nested modules, dynamic loading, CORBA, ...).
However, the kind of programs that we wanted to run efficiently were
different. The basic set of features that we started with included
unique modes for destructive update, so that you could for example do
in-place manipulation of arrays, but apart from that we haven't put
much emphasis on array computations. In contrast, array computations
were certainly the main focus for the Sisal group and probably also
for the SAC developers (though I don't know as much about SAC).
Another difference is the approach to parallelism. Having seen many
parallel logic programming implementations suffer from problems with
overhead, we wanted to get very good performance on the sequential
implementation before worrying about parallelism. So for us,
parallelism was not part of the original set of basic features,
but was instead (and still remains ;-) one of the additional features
to be added later. But for SISAL and (I think) SAC, parallelism was
very much there from the very start. Another difference is that the
kind of parallelism that we were interested in exploiting was different
to that used for SISAL and (I suspect) SAC, again reflecting
differences in the kinds of programs we were focussing on.
A final point for me to make here is that as well as ensuring that
additional features don't compromise the efficiency of the basic model,
we've also been careful to ensure that the additional features do not
compromise the semantics either. That approach is of course nothing
new in the functional language community, but contrasts strongly
with the approach that many in the logic programming community have
taken ;-)
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
