Difference between revision 44 and revision 45

Summary: Give up flame war. Minor edits. Move material to Talk.

No diff available.

Emacs Lisp supports multiple programming styles or paradigms, including functional and object-oriented. Emacs Lisp is not a purely functional programming language since side effects are common. Instead, Emacs Lisp is considered an early functional flavored language. The following features contribute to the functional flavor:

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 (funarg problems, dynamic scoping problems). Emacs Lisp can be written in a declarative style, minimizing side effects, but in practice this never happens. Most Emacs Lisp code will be written in an imperative, procedural style. As a result, programs in purely functional languages enjoy the desirable property of referential transparency where as programs written in Emacs Lisp do not.

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 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.”[1]

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 Prolog in the Logic Programming community.)