Functional Languages

I got involved in a long argument last night centering around different language paradigms and how the perl language fits into them. My “worth adversary” argued that perl could be considered a functional language at least in some ways because it supported function language constructs. In particular the example was given: map { freq $_ } @list The particular point being made here was that perl supported passing code into functions as parameters and that was a principle construct of functional languages. In Java you’d need to use an object to pass the function in as data thus it’s object-oriented and not functional. Now that I’m home and have access to my text books, I can safely put this argument to rest too. From Programming Language Essentials by Henri E. Bal and Dick Grune and published by Addison-Wesley:

A functional (or applicative) language is based on the evaluation of expressions built out of function calls (applications). A function … computes a certain value, based on its input parameters (also called arguments) and nothing else.

The key issue here is that functions cannot have side-effects on the state of the program, unless this state is carried around in the arguments of the functions. This lack of side-effects results in a property called referential-transparency, which is the most important term in functional programming. It means the result of a function application does not depend on when the function is called but only on how it is called (with which arguments). So the most important tenant of a functional language is the fact that functions can’t have side effects – not that they don’t, they can’t. Later it goes on to talk about higher-order functions (functions which take other functions as arguments) and says:

Functional languages usually treat functions as first-class objects, which can be passed as arguments, returned as function results, and stored in data structures Note two key terms here: usually and first-class objects. Usually – because it implies that this is not an essential feature of functional languages, though it is a useful one. First-class objects – because, while they don’t really mean objects in the object oriented sense, they do mean that the function is an entity in itself and that representing it as an actual object isn’t such a big leap, nor is representing it as a function pointer in a language like C. It’s also worth pointing out that these functions can not only be passed in, but also returned, stored in data structures and “curried” or partially parametized. Anyway, what this really shows is that keeping your old text books around can occasionally be useful…