Paradigm | Multi-paradigm: procedural, functional, object-oriented, meta, reflective, generic |
---|---|
Family | Lisp |
Designed by | Scott Fahlman, Richard P. Gabriel, David A. Moon, Guy Steele, Dan Weinreb |
Developer | ANSI X3J13 committee |
First appeared | 1984, 1994 for ANSI Common Lisp |
Typing discipline | dynamic, strong |
Scope | lexical, optionally dynamic |
OS | Cross-platform |
Filename extensions | .lisp, .lsp, .l, .cl, .fasl |
Website | common-lisp |
Major implementations | |
Allegro CL, ABCL, CLISP, Clozure CL, CMUCL, ECL, GCL, LispWorks, Scieneer CL, SBCL, Symbolics Common Lisp | |
Dialects | |
CLtL1, CLtL2, ANSI Common Lisp | |
Influenced by | |
Lisp, Lisp Machine Lisp, Maclisp, Scheme, Interlisp | |
Influenced | |
Clojure, Dylan, Emacs Lisp, EuLisp, ISLISP, Julia, Moose, R, SKILL, SubL |
Common Lisp (CL) is a dialect of the Lisp programming language, published in ANSI standard document ANSI INCITS 226-1994 (R2004) (formerly X3.226-1994 (R1999)). The Common Lisp HyperSpec, a hyperlinked HTML version, has been derived from the ANSI Common Lisp standard.
The Common Lisp language was developed as a standardized and improved successor of Maclisp. By the early 1980s several groups were already at work on diverse successors to MacLisp: Lisp Machine Lisp (aka ZetaLisp), Spice Lisp, NIL and S-1 Lisp. Common Lisp sought to unify, standardise, and extend the features of these MacLisp dialects. Common Lisp is not an implementation, but rather a language specification. Several implementations of the Common Lisp standard are available, including free and open-source software and proprietary products. Common Lisp is a general-purpose, multi-paradigm programming language. It supports a combination of procedural, functional, and object-oriented programming paradigms. As a dynamic programming language, it facilitates evolutionary and incremental software development, with iterative compilation into efficient run-time programs. This incremental development is often done interactively without interrupting the running application.
It also supports optional type annotation and casting, which can be added as necessary at the later profiling and optimization stages, to permit the compiler to generate more efficient code. For instance, fixnum
can hold an unboxed integer in a range supported by the hardware and implementation, permitting more efficient arithmetic than on big integers or arbitrary precision types. Similarly, the compiler can be told on a per-module or per-function basis which type safety level is wanted, using optimize declarations.