## Functional Programming and Lists

Functional Programming and Lists

The essence of functional programming is that programs are built entirely of functions with no side effects that compute their results based solely on the values of their arguments. The advantage of the functional style is that it makes programs easier to understand. Eliminating side effects eliminates almost all possibilities for action at a distance. And since the result of a function is determined only by the values of its arguments, its behavior is easier to understand and test. For instance, when you see an expression such as `(+ 3 4)`, you know the result is uniquely determined by the definition of the `+` function and the values `3` and `4`. You don't have to worry about what may have happened earlier in the execution of the program since there's nothing that can change the result of evaluating that expression.

Functions that deal with numbers are naturally functional since numbers are immutable. A list, on the other hand, can be mutated, as you've just seen, by `SETF`ing the `CAR`s and `CDR`s of the cons cells that make up its backbone. However, lists can be treated as a functional data type if you consider their value to be determined by the elements they contain. Thus, any list of the form `(1 2 3 4)` is functionally equivalent to any other list containing those four values, regardless of what cons cells are actually used to represent the list. And any function that takes a list as an argument and returns a value based solely on the contents of the list can likewise be considered functional. For instance, the `REVERSE` sequence function, given the list `(1 2 3 4)`, always returns a list `(4 3 2 1)`. Different calls to `REVERSE` with functionally equivalent lists as the argument will return functionally equivalent result lists. Another aspect of functional programming, which I'll discuss in the section "Mapping," is the use of higher-order functions: functions that treat other functions as data, taking them as arguments or returning them as results.

Most of Common Lisp's list-manipulation functions are written in a functional style. I'll discuss later how to mix functional and other coding styles, but first you should understand a few subtleties of the functional style as applied to lists.

The reason most list functions are written functionally is it allows them to return results that share cons cells with their arguments. To take a concrete example, the function `APPEND` takes any number of list arguments and returns a new list containing the elements of all its arguments. For instance:

`(append (list 1 2) (list 3 4)) ==> (1 2 3 4)`

From a functional point of view, `APPEND`'s job is to return the list `(1 2 3 4)` without modifying any of the cons cells in the lists `(1 2)` and `(3 4)`. One obvious way to achieve that goal is to create a completely new list consisting of four new cons cells. However, that's more work than is necessary. Instead, `APPEND` actually makes only two new cons cells to hold the values `1` and `2`, linking them together and pointing the `CDR` of the second cons cell at the head of the last argument, the list `(3 4)`. It then returns the cons cell containing the `1`. None of the original cons cells has been modified, and the result is indeed the list `(1 2 3 4)`. The only wrinkle is that the list returned by `APPEND` shares some cons cells with the list `(3 4)`. The resulting structure looks like this:

In general, `APPEND` must copy all but its last argument, but it can always return a result that shares structure with the last argument.

Other functions take similar advantage of lists' ability to share structure. Some, like `APPEND`, are specified to always return results that share structure in a particular way. Others are simply allowed to return shared structure at the discretion of the implementation.

Оглавление книги

Генерация: 0.033. Запросов К БД/Cache: 0 / 0
поделиться
Вверх Вниз