Are closures with side-effects considered "functional style"?

Question

Many modern programming languages support some concept of closure, i.e. of a piece of code (a block or a function) that

1. Can be treated as a value, and therefore stored in a variable, passed around to different parts of the code, be defined in one part of a program and invoked in a totally different part of the same program.
2. Can capture variables from the context in which it is defined, and access them when it is later invoked (possibly in a totally different context).

Here is an example of a closure written in Scala:

def filterList(xs: List[Int], lowerBound: Int): List[Int] =
  xs.filter(x => x >= lowerBound)

The function literal x => x >= lowerBound contains the free variable lowerBound, which is closed (bound) by the argument of the function filterList that has the same name. The closure is passed to the library method filter, which can invoke it repeatedly as a normal function.

I have been reading a lot of questions and answers on this site and, as far as I understand, the term closure is often automatically associated with functional programming and functional programming style.

The definition of function programming on wikipedia reads:

In computer science, functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data. It emphasizes the application of functions, in contrast to the imperative programming style, which emphasizes changes in state.

and further on

[...] in functional code, the output value of a function depends only on the arguments that are input to the function [...]. Eliminating side effects can make it much easier to understand and predict the behavior of a program, which is one of the key motivations for the development of functional programming.

On the other hand, many closure constructs provided by programming languages allow a closure to capture non-local variables and change them when the closure is invoked, thus producing a side effect on the environment in which they were defined.

In this case, closures implement the first idea of functional programming (functions are first-class entities that can be moved around like other values) but neglect the second idea (avoiding side-effects).

Is this use of closures with side effects considered functional style or are closures considered a more general construct that can be used both for a functional and a non-functional programming style? Is there any literature on this topic?

IMPORTANT NOTE

I am not questioning the usefulness of side-effects or of having closures with side effects. Also, I am not interested in a discussion about the advantages / disadvantages of closures with or without side effects.

I am only interested to know if using such closures is still considered functional style by the proponent of functional programming or if, on the contrary, their use is discouraged when using a functional style.

Answer 1

No; the definition of functional paradigm is about lack of state and implicitly lack of side-effects. It is not about high-order functions, closures, language supported list manipulation or others language features...

The name of functional programming comes from the mathematical notion of functions - repeated calls on the same input always gives the same output - nullipotent function. This can only be achieved if the data is immutable. In order to ease development, the functions became mutable (functions change, data is still immutable) and thus the notion of higher-order functions (functionals in mathematics, as derivatives for example) - a function that takes as input another function. For the possibility of functions to be carried around and passed as arguments, first-class functions were adopted; following these, to further enhance productivity, closures appeared.

This is, of course, a very simplified view.

Answer 2

No. "Functional-style" implies side-effect-free programming.

To see why, have a look at Eric Lippert's blog entry about the ForEach<T> extension method, and why Microsoft didn't include a sequence method like it in Linq:

I am philosophically opposed to providing such a method, for two reasons.

The first reason is that doing so violates the functional programming principles that all the other sequence operators are based upon. Clearly the sole purpose of a call to this method is to cause side effects. The purpose of an expression is to compute a value, not to cause a side effect. The purpose of a statement is to cause a side effect. The call site of this thing would look an awful lot like an expression (though, admittedly, since the method is void-returning, the expression could only be used in a “statement expression” context.) It does not sit well with me to make the one and only sequence operator that is only useful for its side effects.

The second reason is that doing so adds zero new representational power to the language. Doing this lets you rewrite this perfectly clear code:

foreach(Foo foo in foos){ statement involving foo; }

into this code:

foos.ForEach((Foo foo)=>{ statement involving foo; });

which uses almost exactly the same characters in slightly different order. And yet the second version is harder to understand, harder to debug, and introduces closure semantics, thereby potentially changing object lifetimes in subtle ways.

Answer 3

Functional programming take first class functions to the next conceptual level for sure, but declaring anonymous functions or passing functions to other functions is not necessarily a functional programming thing. In C, everything was an integer. A number, a pointer to data, a pointer to a function... all just ints. You could pass function pointers to other functions, make lists of function pointers... Heck, if you work in assembly language, functions are really just addresses in memory where blocks of machine instructions are stored. Giving a function a name is extra overhead for the people who need a compiler to write code. So functions were "first-class" in that sense in a completely non-functional language.

If the only thing you do is calculate mathematical formulas in a REPL, then you can be functionally pure with your language. But most business programming has side effects. Losing money while waiting for a long-running program to complete is a side effect. Taking any external action: writing to a file, updating a database, logging events in order, etc. requires a change of state. We could debate about whether state is really changed if you encapsulate these actions in immutable wrappers that push side-effects off so that your code doesn't have to worry about them. But it's like discussing whether a tree makes a noise if it falls in the forest with no-one there to hear it. The fact is that the tree started upright and ended up on the ground. State gets changed when stuff gets done, even if only to report that the stuff got done. True purity in functional programming is only fully realized in isolated sections of code or on paper - not in real, useful programs as a whole.

So we are left with a scale of functional purity, not black and white, but shades of gray. And on that scale, the fewer side effects, the less mutability, the better (more functional).

If you absolutely require side effect or mutable state in your otherwise functional code, you strive to encapsulate or it from the rest of your program as best you can. Using a closure (or anything else) to inject side effects or mutable state into otherwise pure functions is the antithesis of functional programming. The only exception might be if the closure were the most effective way to encapsulate the side effects from the code it is passed to. It's still not "functional programming" but it might be the closet you can get in certain situations.