.\" Copyright (c) 1980 The Regents of the University of California.
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" @(#)manCh1.rno 6.2 (Berkeley) 4/17/91
\fBFP\fP stands for a \fIFunctional Programming\fP language.
deal with \fIfunctions\fP instead of \fIvalues\fP.
There is no explicit representation of state, there are
no assignment statments, and hence,
Owing to the lack of state, FP functions are free from
say the FP is \fIapplicative\fP.
All functions take one argument and they are evaluated using
operation, \fIapplication\fP (the colon ':' is the apply operator).
For example, we read $~+^:^<3~4>~$ as \*(lqapply
the function '+' to its argument <3 4>\*(rq.
Functional programs express a functional-level combination of
instead of describing state changes using value-oriented
For example, we write the function returning the
\fIsin\fP of the \fIcos\fP
of its input, \*(IE $sin(cos(x))$, as:
$sin^@^cos$. This is a \fIfunctional expression\fP, consisting
of the single \fIcombining form\fP called \fIcompose\fP ('@'
and its \fIfunctional arguments\fP \fIsin\fP and \fIcos\fP.
All combining forms take functions as arguments and return
functions as results; functions may either be applied,
$sin @ cos^:^3$, or used as a functional argument in another functional
expression, \*(EG \fItan @ sin @ cos\fP.
FP's combining forms allow us to express
control abstractions without the use of variables.
The \fIapply to all\fP functional form (&)
is another case in point. The function '& exp'
exponentiates all the elements of its argument:
"&exp : <1.0 2.0>" ~==~ "<2.718 7.389>"
no induction variables, nor a
loop bounds specification.
Moreover, the code is useful for any size argument,
so long as the sub-elements of its argument conform to the domain of the
We must change our view of the programming process
to adapt to the functional
Instead of writing down a set of steps that manipulate and assign values,
we compose functional expressions
the higher-level functional forms.
For example, the function that adds a
scalar to all elements of a vector will be written in two steps. First,
the function that distributes the scalar amongst each element
"distl : <3 <4 6>>" ~==~ "<<3 4> <3 6>>"
Next, the function that adds the pairs of elements that
"&+ : <<3 4> <3 6>>" ~==~ "<7 9>"
In a value-oriented programming language the computation
"&+ : distl : <3 <4 6>>,"
which means to apply 'distl' to the input and then to apply '+'
to every element of the result.
"&+ @ distl : <3 <4 6>>."
The functional expression of (1.5) replaces
the two step value expression of (1.4).
functional expressions are built from the inside out,
In the next example we derive a function that scales then
shifts a vector, \*(IE for scalars $a,~b^$ and a vector $v vec$,
compute $a~+~b v vec$. This FP function will have three
arguments, namely $a,~b~$ and $~v vec$. Of course, FP
does not use formal parameter names, so
they will be designated by the function symbols 1, 2, 3.
The first code segment scales $v vec~$ by $b$ (defintions
are delimited with curly braces '{}'):
"{scaleVec &\(** @ distl @ [2,3]}"
The code segment in (1.5)
The completed function is:
"{changeVec &+ @ distl @ [1 , scaleVec]}"
In the derivation of the program we wrote from right to left,
first doing the \fIdistl\fP's and then composing with the
\fIapply-to-all\fP functional form.
Using an imperative language, such as Pascal,
we would write the program from
the outside in, writing the loop
before inserting the arithmetic operators.
FP encourages a recursive programming style,
it provides combining forms to avoid explicit recursion.
right insert combining form (!)
can be used to write a function
that adds up a list of numbers:
The equivalent, recursive function is much longer:
"{addNumbers (null -> %0 ; + @ [1, addNumbers @ tl])}"
The generality of the combining forms encourages hierarchical
program development. Unlike APL,
the use of combining forms to certain builtin functions,
FP allows combining forms to take any functional expression as
projects / unix-history / blob