Résumé : Rückgängig gemacht auf den Stand vom 2013-08-24 11:21 UTC
< On the other hand, ''Scheme Editor Committee'' member [[WikiPedia:Special:WikiModes/Anton_van_Straaten|Anton van Straaten]]
> On the other hand, ''Scheme Editor Committee'' member [[WikiPedia:Special:Search/Anton_van_Straaten|Anton van Straaten]]
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:
In a keynote address in 2012, Turner updated his characterization of Lisp:
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:
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.