Christopher B. Browne's Home Page

7. Functional Programming Languages

7.1. Introduction

In the realm of computing, the term functional tends to take on two very distinct meanings:

From the comp.lang.functional FAQ comes the following: "Functional programming is a style of programming that emphasizes the evaluation of expressions, rather than execution of commands. The expressions in these language are formed by using functions to combine basic values. A functional language is a language that supports and encourages programming in a functional style. "

In an imperative language, one might describe an algorithm for adding values together to get a sum thus:

    for (i = 0, sum = 0; i <= 100; i++ )
      sum += i;

The functional equivalent would be expressed without any variable updates (e.g. operations upon whose side-effects the process depends), perhaps as:


(Haskell /Miranda) or

    (define (iota size)
        (<= size 0)
        (cons size (iota (- size 1)))))
    (define (sum size)
      (apply + (iota size))
    (sum 10)

( Scheme )

It is commonly possible to write code in a relatively functional style even in "imperative" languages, and vice-versa. For instance, Scheme programs commonly do have the side-effect of modifying data.

Major benefits of functional programming include that:

7.2. ML

ML (which stands for "meta language") is a family of programming languages characterized by functional control structures, strict semantics, a strict polymorphic type system, and parametrized modules. There are a number of implementations, and it is fairly widely used as a teaching language in computer science programs.

7.3. Haskell

7.4. Lazy Evaluation

One of the important characteristics of Haskell is the ability to readily use lazy evaluation.

Lazy evaluation is an evaluation strategy combining normal order evaluation with updating. Under this strategy, an expression is evaluated only when its value is needed in order for the program to return (perhaps just the next part of) its result.

It holds parallels to the OR notion of Dynamic Programming as well as to spreadsheets where values are only computed as required.

7.5. Poplog

7.6. J and APL Stuff

The "wars" on comp.lang.apl have typically been over whether the apl in comp.lang.apl ought to be considered to stand for A Programming Language, thus ruling out discussion of similar languages that are not, strictly speaking, APL implementation, or whether it ought to be considered to stand for Array Processing Languages, which, of course opens up discussion to J, K, and perhaps NIAL.

It's not as if there's so much traffic concerning either variety of language as to cause the problems they have on the comp.lang.c hierarchy...

7.7. Other Functional Languages

Contact me at