Emacs Lisp supports *multiple programming styles* or paradigms, including *functional* and *object-oriented*.
Emacs Lisp is not a [[WikiPedia:Purely functional|purely functional]] programming language since [[WikiPedia:Side effect (computer science)|side effects]] are common.
Instead, Emacs Lisp is considered [[WikiPedia:Functional_programming|an early functional flavored language]]. The following features contribute to the functional flavor:

* its notation is functional (including a lambda calculus-like notation -- see LambdaExpression)
* its constructs are expressions ([[sexp]]s), which are evaluated and return values
* it supports recursive program definition (even though it does not provide for [[WikiPedia:Tail call|optimized tail recursion]] and [[WikiPedia:Lazy evaluation|lazy evaluation]])
* it supports the creation and use of higher-order programs (using `apply', `funcall', and `eval' in particular)

On the other hand, Emacs Lisp does not treat functions as first-class language constructs -- higher-order support for functions (even true functions) is limited and erroneous ([[WikiPedia:Funarg_problem|funarg]] problems, [[WikiPedia:Scope|dynamic scoping]] problems). Emacs Lisp can be written in a  [[WikiPedia:Declarative_programming|declarative]] style, minimizing [[WikiPedia:Side effect (computer science)|side effects]], but in practice this never happens. Most Emacs Lisp code will be written in an [[WikiPedia:Imperative_programming|imperative]], [[WikiPedia:Procedural_programming|procedural]] style. As a result, programs in purely functional languages enjoy the desirable property of [[WikiPedia:Referential transparency (computer science)|referential transparency]] where as programs written in Emacs Lisp do not.

[[WikiPedia:David_Turner_(computer_scientist)|David Turner]], responsible for the first purely functional, fully lazy functional language implementations (SASL, KRC, Miranda), had this to say about Lisp in 1985:

: It needs to be said very firmly that LISP, at least as represented
by the dialects in common use, is not a functional language at
all. LISP does have a functional subset, but that is a rather
inconvenient programming language and there exists no significant body
of programs written in it. Almost all serious programming in LISP
makes heavy use of side effects and other referentially opaque
features. --- in ''Mathematical Logic and
Programming Languages'' (1985) edited by C.A.R. Hoare,
J. C. Shepherdson

In a keynote address in 2012, Turner updated his characterization of Lisp:

: "Pure LISP" never existed - LISP had assignment and GOTO before it had conditional expressions and recursion.  LISP  was not based on the lambda calculus, despite using the word "lambda" to denote functions.   Not until SCHEME (Sussman 1975) did versions of LISP with static binding appear.  Today all versions of LISP are lambda calculus based. --- from ''Some History of Functional Programming Languages'', Symposium on Trends in Functional Programming (2012)

He thus points out that although today's Lisps are still not purely functional (they have assignment etc.), unlike the first Lisps, they all make at least some use of static binding, and to that extent they are based on the lambda calculus.  This is true also of EmacsLisp, starting with Emacs 24.

On the other hand, ''Scheme Editor Committee'' member [[WikiPedia:Special:Search/Anton_van_Straaten|Anton van Straaten]]
said this about Lisp and Scheme in 2003:

: "[Its] functional capabilities are complete --- it's
not lacking anything that a functional language needs to be considered
functional."[http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03242.html]

Turner and van Straaten thus agree that Lisp has a functional subset that is complete.  The difference in perspective is with respect to the actual ''use'' of Lisp versus its functional subset.

Is Lisp functional because it is ''not lacking'' anything needed for a functional language (van Straaten)?  Or is it ''not'' functional because it ''also has'' lots of stuff that is imperative and procedural (Turner)?

Those who see the Lisp functional glass half empty emphasize the fact that in practice Lisp/Scheme is typically ''not'' used as a functional language.  Those who see it half full emphasize the fact that you ''can'' restrict yourself to using "pure Lisp", that is, the functional subset.  

(Analogous opposing views can be found wrt [[WikiPedia:Prolog|Prolog]] in the [[WikiPedia:Logic_Programming|Logic Programming]] community.)

----
CategoryCode