🚀 go-pugleaf

clin@eng.umd.edu (Charles Lin) writes:


>   Well, a while back, I asked people why functional languages were useful,
>interesting, etc.   I have two followup questions, and unfortunately
>I was a little lazy and didn't type the correct sunject heading, which
>should have been "Why are you interested in functional languages?".

>   So, I'm interested in why you wanted to do work in this area, and
>also what you think the important kinds of questions or work will
>be done in the area, either now, or in the future.

My primary interest in functional languages is not ease of programming
from a human viewpoint (after all, adding imperative features to a
pure FL will not make programming in it harder), but the ease of
manipulating programs.

The high degree of referential transparency in functional laguages
makes many transformations possible, which would not always be valid
in the presence of side-effects, and thus requires a global test of
interference before it can be applied in an imperative language. A
simpe example of this is common subexpression elimination. If you
write "f(x)+f(x)" you would like to transform it into something like
"y+y where y=f(x)" which you couldn't in an imperative language as the
two calls might yield different results, or even modify x. An analysis
of the behaviour of f in an imperative setting could check that it
behaves functionally, but that is both difficult (in most imperative
languages) and costly.

Note that I'm not against side effects as an algorithmic tool (far
from it), only the effects they have on the validity of
transformations. If a language provided a mostly functional framework,
but allowed limited side effects with clear indication (e.g. in the
type system) of what each given function depends on or can modify,
then the transformation rules can use this information to check the
validity of each given transformation. SML goes some way towards this
with the special types for side-effects, but the information is not
exactly what I need.

Even in basically imperative languages, there are degrees of
"badness". In C you have enourmous aliasing problems, as pointers can
refer to local variables, so updating what a pointer refers to can
essentially modify anything. In Pascal, pointers can only refer to
heap objects, so it is easier to determine the potential effects. You
have, off course, aliasing in Pascal too (by var parameters), but it
is less severe than in C.

As you might have guessed, C is my pet hate language. Even so, I
program mostly in C (when i'm not using functional languages, that
is), but I would not try to do automatic transformation of C programs.

The important future works in pure functional languages are:

1) Make it easy to describe functionally algorithms that are
   traditionally written in imperative style with arrays and pointer
   updating. The "standard trick" of adding the state as extra
   parameters/results of functions is notationally burdensome.

2) Make such algorithms run efficiently. The abovementioned trick adds
   a lot of overhead. Also, operations on arrays can be costly if
   implemented in the obvious ways.

3) Make good parallel implementations of functional languages, getting
   good processor utilisation without requiring programs to be written
   specifically for a given architecture.

Much work is already done in these areas, but there is still room for
improvement.

	Torben Mogensen (torbenm@diku.dk)