Common Lisp

From Wikipedia for FEVERv2
Jump to navigation Jump to search

Common Lisp_table_infobox_0

Common LispCommon Lisp_table_caption_0
ParadigmCommon Lisp_header_cell_0_0_0 Multi-paradigm: procedural, functional, object-oriented, meta, reflective, genericCommon Lisp_cell_0_0_1
FamilyCommon Lisp_header_cell_0_1_0 LispCommon Lisp_cell_0_1_1
Designed byCommon Lisp_header_cell_0_2_0 Scott Fahlman, Richard P. Gabriel, David A. Moon, Kent Pitman, Guy Steele, Dan WeinrebCommon Lisp_cell_0_2_1
DeveloperCommon Lisp_header_cell_0_3_0 ANSI X3J13 committeeCommon Lisp_cell_0_3_1
First appearedCommon Lisp_header_cell_0_4_0 1984 (36 years ago) (1984), 1994 (26 years ago) (1994) for ANSI Common LispCommon Lisp_cell_0_4_1
Typing disciplineCommon Lisp_header_cell_0_5_0 Dynamic, strongCommon Lisp_cell_0_5_1
ScopeCommon Lisp_header_cell_0_6_0 Lexical, optionally dynamicCommon Lisp_cell_0_6_1
OSCommon Lisp_header_cell_0_7_0 Cross-platformCommon Lisp_cell_0_7_1
Common Lisp_header_cell_0_8_0 .lisp, .lsp, .l, .cl, .faslCommon Lisp_cell_0_8_1
WebsiteCommon Lisp_header_cell_0_9_0 Common Lisp_cell_0_9_1
Major implementationsCommon Lisp_header_cell_0_10_0
DialectsCommon Lisp_header_cell_0_11_0
Influenced byCommon Lisp_header_cell_0_12_0
InfluencedCommon Lisp_header_cell_0_13_0

Common Lisp (CL) is a dialect of the Lisp programming language, published in ANSI standard document ANSI INCITS 226-1994 [S2008] (formerly X3.226-1994 (R1999)). Common Lisp_sentence_0

The Common Lisp HyperSpec, a hyperlinked HTML version, has been derived from the ANSI Common Lisp standard. Common Lisp_sentence_1

The Common Lisp language was developed as a standardized and improved successor of Maclisp. Common Lisp_sentence_2

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_sentence_3

Common Lisp sought to unify, standardise, and extend the features of these MacLisp dialects. Common Lisp_sentence_4

Common Lisp is not an implementation, but rather a language specification. Common Lisp_sentence_5

Several implementations of the Common Lisp standard are available, including free and open-source software and proprietary products. Common Lisp_sentence_6

Common Lisp is a general-purpose, multi-paradigm programming language. Common Lisp_sentence_7

It supports a combination of procedural, functional, and object-oriented programming paradigms. Common Lisp_sentence_8

As a dynamic programming language, it facilitates evolutionary and incremental software development, with iterative compilation into efficient run-time programs. Common Lisp_sentence_9

This incremental development is often done interactively without interrupting the running application. Common Lisp_sentence_10

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. Common Lisp_sentence_11

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. Common Lisp_sentence_12

Similarly, the compiler can be told on a per-module or per-function basis which type of safety level is wanted, using optimize declarations. Common Lisp_sentence_13

Common Lisp includes CLOS, an object system that supports multimethods and method combinations. Common Lisp_sentence_14

It is often implemented with a Metaobject Protocol. Common Lisp_sentence_15

Common Lisp is extensible through standard features such as Lisp macros (code transformations) and reader macros (input parsers for characters). Common Lisp_sentence_16

Common Lisp provides partial backwards compatibility with Maclisp and John McCarthy's original Lisp. Common Lisp_sentence_17

This allows older Lisp software to be ported to Common Lisp. Common Lisp_sentence_18

History Common Lisp_section_0

Work on Common Lisp started in 1981 after an initiative by ARPA manager Bob Engelmore to develop a single community standard Lisp dialect. Common Lisp_sentence_19

Much of the initial language design was done via electronic mail. Common Lisp_sentence_20

In 1982, Guy L. Steele, Jr. gave the first overview of Common Lisp at the 1982 ACM Symposium on LISP and functional programming. Common Lisp_sentence_21

The first language documentation was published in 1984 as Common Lisp the Language (known as CLtL1), first edition. Common Lisp_sentence_22

A second edition (known as CLtL2), published in 1990, incorporated many changes to the language, made during the ANSI Common Lisp standardization process: extended LOOP syntax, the Common Lisp Object System, the Condition System for error handling, an interface to the pretty printer and much more. Common Lisp_sentence_23

But CLtL2 does not describe the final ANSI Common Lisp standard and thus is not a documentation of ANSI Common Lisp. Common Lisp_sentence_24

The final ANSI Common Lisp standard then was published in 1994. Common Lisp_sentence_25

Since then no update to the standard has been published. Common Lisp_sentence_26

Various extensions and improvements to Common Lisp (examples are Unicode, Concurrency, CLOS-based IO) have been provided by implementations and libraries. Common Lisp_sentence_27

Syntax Common Lisp_section_1

Common Lisp is a dialect of Lisp. Common Lisp_sentence_28

It uses S-expressions to denote both code and data structure. Common Lisp_sentence_29

Function calls, macro forms and special forms are written as lists, with the name of the operator first, as in these examples: Common Lisp_sentence_30

Data types Common Lisp_section_2

Common Lisp has many data types. Common Lisp_sentence_31

Scalar types Common Lisp_section_3

Number types include integers, ratios, floating-point numbers, and complex numbers. Common Lisp_sentence_32

Common Lisp uses bignums to represent numerical values of arbitrary size and precision. Common Lisp_sentence_33

The ratio type represents fractions exactly, a facility not available in many languages. Common Lisp_sentence_34

Common Lisp automatically coerces numeric values among these types as appropriate. Common Lisp_sentence_35

The Common Lisp character type is not limited to ASCII characters. Common Lisp_sentence_36

Most modern implementations allow Unicode characters. Common Lisp_sentence_37

The symbol type is common to Lisp languages, but largely unknown outside them. Common Lisp_sentence_38

A symbol is a unique, named data object with several parts: name, value, function, property list, and package. Common Lisp_sentence_39

Of these, value cell and function cell are the most important. Common Lisp_sentence_40

Symbols in Lisp are often used similarly to identifiers in other languages: to hold the value of a variable; however there are many other uses. Common Lisp_sentence_41

Normally, when a symbol is evaluated, its value is returned. Common Lisp_sentence_42

Some symbols evaluate to themselves, for example, all symbols in the keyword package are self-evaluating. Common Lisp_sentence_43

Boolean values in Common Lisp are represented by the self-evaluating symbols T and NIL. Common Lisp has namespaces for symbols, called 'packages'. Common Lisp_sentence_44

A number of functions are available for rounding scalar numeric values in various ways. Common Lisp_sentence_45

The function round rounds the argument to the nearest integer, with halfway cases rounded to the even integer. Common Lisp_sentence_46

The functions truncate, floor, and ceiling round towards zero, down, or up respectively. Common Lisp_sentence_47

All these functions return the discarded fractional part as a secondary value. Common Lisp_sentence_48

For example, (floor -2.5) yields −3, 0.5; (ceiling -2.5) yields −2, −0.5; (round 2.5) yields 2, 0.5; and (round 3.5) yields 4, −0.5. Common Lisp_sentence_49

Data structures Common Lisp_section_4

Sequence types in Common Lisp include lists, vectors, bit-vectors, and strings. Common Lisp_sentence_50

There are many operations that can work on any sequence type. Common Lisp_sentence_51

As in almost all other Lisp dialects, lists in Common Lisp are composed of conses, sometimes called cons cells or pairs. Common Lisp_sentence_52

A cons is a data structure with two slots, called its car and cdr. Common Lisp_sentence_53

A list is a linked chain of conses or the empty list. Common Lisp_sentence_54

Each cons's car refers to a member of the list (possibly another list). Common Lisp_sentence_55

Each cons's cdr refers to the next cons—except for the last cons in a list, whose cdr refers to the nil value. Common Lisp_sentence_56

Conses can also easily be used to implement trees and other complex data structures; though it is usually advised to use structure or class instances instead. Common Lisp_sentence_57

It is also possible to create circular data structures with conses. Common Lisp_sentence_58

Common Lisp supports multidimensional arrays, and can dynamically resize adjustable arrays if required. Common Lisp_sentence_59

Multidimensional arrays can be used for matrix mathematics. Common Lisp_sentence_60

A vector is a one-dimensional array. Common Lisp_sentence_61

Arrays can carry any type as members (even mixed types in the same array) or can be specialized to contain a specific type of members, as in a vector of bits. Common Lisp_sentence_62

Usually, only a few types are supported. Common Lisp_sentence_63

Many implementations can optimize array functions when the array used is type-specialized. Common Lisp_sentence_64

Two type-specialized array types are standard: a string is a vector of characters, while a bit-vector is a vector of bits. Common Lisp_sentence_65

Hash tables store associations between data objects. Common Lisp_sentence_66

Any object may be used as key or value. Common Lisp_sentence_67

Hash tables are automatically resized as needed. Common Lisp_sentence_68

Packages are collections of symbols, used chiefly to separate the parts of a program into namespaces. Common Lisp_sentence_69

A package may export some symbols, marking them as part of a public interface. Common Lisp_sentence_70

Packages can use other packages. Common Lisp_sentence_71

Structures, similar in use to C structs and Pascal records, represent arbitrary complex data structures with any number and type of fields (called slots). Common Lisp_sentence_72

Structures allow single-inheritance. Common Lisp_sentence_73

Classes are similar to structures, but offer more dynamic features and multiple-inheritance. Common Lisp_sentence_74

(See CLOS). Common Lisp_sentence_75

Classes have been added late to Common Lisp and there is some conceptual overlap with structures. Common Lisp_sentence_76

Objects created of classes are called Instances. Common Lisp_sentence_77

A special case is Generic Functions. Common Lisp_sentence_78

Generic Functions are both functions and instances. Common Lisp_sentence_79

Functions Common Lisp_section_5

Common Lisp supports first-class functions. Common Lisp_sentence_80

For instance, it is possible to write functions that take other functions as arguments or return functions as well. Common Lisp_sentence_81

This makes it possible to describe very general operations. Common Lisp_sentence_82

The Common Lisp library relies heavily on such higher-order functions. Common Lisp_sentence_83

For example, the sort function takes a relational operator as an argument and key function as an optional keyword argument. Common Lisp_sentence_84

This can be used not only to sort any type of data, but also to sort data structures according to a key. Common Lisp_sentence_85

The evaluation model for functions is very simple. Common Lisp_sentence_86

When the evaluator encounters a form (f a1 a2...) then it presumes that the symbol named f is one of the following: Common Lisp_sentence_87

Common Lisp_ordered_list_0

  1. A special operator (easily checked against a fixed list)Common Lisp_item_0_0
  2. A macro operator (must have been defined previously)Common Lisp_item_0_1
  3. The name of a function (default), which may either be a symbol, or a sub-form beginning with the symbol lambda.Common Lisp_item_0_2

If f is the name of a function, then the arguments a1, a2, ..., an are evaluated in left-to-right order, and the function is found and invoked with those values supplied as parameters. Common Lisp_sentence_88

Defining functions Common Lisp_section_6

The macro defun defines functions where a function definition gives the name of the function, the names of any arguments, and a function body: Common Lisp_sentence_89

Function definitions may include compiler directives, known as declarations, which provide hints to the compiler about optimization settings or the data types of arguments. Common Lisp_sentence_90

They may also include documentation strings (docstrings), which the Lisp system may use to provide interactive documentation: Common Lisp_sentence_91

Anonymous functions (function literals) are defined using lambda expressions, e.g. (lambda (x) (* x x)) for a function that squares its argument. Common Lisp_sentence_92

Lisp programming style frequently uses higher-order functions for which it is useful to provide anonymous functions as arguments. Common Lisp_sentence_93

Local functions can be defined with flet and labels. Common Lisp_sentence_94

There are several other operators related to the definition and manipulation of functions. Common Lisp_sentence_95

For instance, a function may be compiled with the compile operator. Common Lisp_sentence_96

(Some Lisp systems run functions using an interpreter by default unless instructed to compile; others compile every function). Common Lisp_sentence_97

Defining generic functions and methods Common Lisp_section_7

The macro defgeneric defines generic functions. Common Lisp_sentence_98

Generic functions are a collection of methods. Common Lisp_sentence_99

The macro defmethod defines methods. Common Lisp_sentence_100

Methods can specialize their parameters over CLOS standard classes, system classes, structure classes or individual objects. Common Lisp_sentence_101

For many types, there are corresponding system classes. Common Lisp_sentence_102

When a generic function is called, multiple-dispatch will determine the effective method to use. Common Lisp_sentence_103

Generic Functions are also a first class data type. Common Lisp_sentence_104

There are many more features to Generic Functions and Methods than described above. Common Lisp_sentence_105

The function namespace Common Lisp_section_8

The namespace for function names is separate from the namespace for data variables. Common Lisp_sentence_106

This is a key difference between Common Lisp and Scheme. Common Lisp_sentence_107

For Common Lisp, operators that define names in the function namespace include defun, flet, labels, defmethod and defgeneric. Common Lisp_sentence_108

To pass a function by name as an argument to another function, one must use the function special operator, commonly abbreviated as #'. Common Lisp_sentence_109

The first sort example above refers to the function named by the symbol > in the function namespace, with the code #'>. Common Lisp_sentence_110

Conversely, to call a function passed in such a way, one would use the funcall operator on the argument. Common Lisp_sentence_111

Scheme's evaluation model is simpler: there is only one namespace, and all positions in the form are evaluated (in any order) – not just the arguments. Common Lisp_sentence_112

Code written in one dialect is therefore sometimes confusing to programmers more experienced in the other. Common Lisp_sentence_113

For instance, many Common Lisp programmers like to use descriptive variable names such as list or string which could cause problems in Scheme, as they would locally shadow function names. Common Lisp_sentence_114

Whether a separate namespace for functions is an advantage is a source of contention in the Lisp community. Common Lisp_sentence_115

It is usually referred to as the Lisp-1 vs. Lisp-2 debate. Common Lisp_sentence_116

Lisp-1 refers to Scheme's model and Lisp-2 refers to Common Lisp's model. Common Lisp_sentence_117

These names were coined in a 1988 paper by Richard P. Gabriel and Kent Pitman, which extensively compares the two approaches. Common Lisp_sentence_118

Multiple return values Common Lisp_section_9

Common Lisp supports the concept of multiple values, where any expression always has a single primary value, but it might also have any number of secondary values, which might be received and inspected by interested callers. Common Lisp_sentence_119

This concept is distinct from returning a list value, as the secondary values are fully optional, and passed via a dedicated side channel. Common Lisp_sentence_120

This means that callers may remain entirely unaware of the secondary values being there if they have no need for them, and it makes it convenient to use the mechanism for communicating information that is sometimes useful, but not always necessary. Common Lisp_sentence_121

For example, Common Lisp_sentence_122

Common Lisp_unordered_list_1

  • The TRUNCATE function rounds the given number to an integer towards zero. However, it also returns a remainder as a secondary value, making it very easy to determine what value was truncated. It also supports an optional divisor parameter, which can be used to perform Euclidean division trivially:Common Lisp_item_1_3

Common Lisp_unordered_list_2

  • GETHASH returns the value of a key in an associative map, or the default value otherwise, and a secondary boolean indicating whether the value was found. Thus code which does not care about whether the value was found or provided as the default can simply use it as-is, but when such distinction is important, it might inspect the secondary boolean and react appropriately. Both use cases are supported by the same call and neither is unnecessarily burdened or constrained by the other. Having this feature at the language level removes the need to check for the existence of the key or compare it to null as would be done in other languages.Common Lisp_item_2_4

Multiple values are supported by a handful of standard forms, most common of which are the MULTIPLE-VALUE-BIND special form for accessing secondary values and VALUES for returning multiple values: Common Lisp_sentence_123

Other types Common Lisp_section_10

Other data types in Common Lisp include: Common Lisp_sentence_124

Common Lisp_unordered_list_3

  • Pathnames represent files and directories in the . The Common Lisp pathname facility is more general than most operating systems' file naming conventions, making Lisp programs' access to files broadly portable across diverse systems.Common Lisp_item_3_5
  • Input and output streams represent sources and sinks of binary or textual data, such as the terminal or open files.Common Lisp_item_3_6
  • Common Lisp has a built-in pseudo-random number generator (PRNG). Random state objects represent reusable sources of pseudo-random numbers, allowing the user to seed the PRNG or cause it to replay a sequence.Common Lisp_item_3_7
  • Conditions are a type used to represent errors, exceptions, and other "interesting" events to which a program may respond.Common Lisp_item_3_8
  • Classes are first-class objects, and are themselves instances of classes called metaobject classes (metaclasses for short).Common Lisp_item_3_9
  • Readtables are a type of object which control how Common Lisp's reader parses the text of source code. By controlling which readtable is in use when code is read in, the programmer can change or extend the language's syntax.Common Lisp_item_3_10

Scope Common Lisp_section_11

Like programs in many other programming languages, Common Lisp programs make use of names to refer to variables, functions, and many other kinds of entities. Common Lisp_sentence_125

Named references are subject to scope. Common Lisp_sentence_126

The association between a name and the entity which the name refers to is called a binding. Common Lisp_sentence_127

Scope refers to the set of circumstances in which a name is determined to have a particular binding. Common Lisp_sentence_128

Determiners of scope Common Lisp_section_12

The circumstances which determine scope in Common Lisp include: Common Lisp_sentence_129

Common Lisp_unordered_list_4

  • the location of a reference within an expression. If it's the leftmost position of a compound, it refers to a special operator or a macro or function binding, otherwise to a variable binding or something else.Common Lisp_item_4_11
  • the kind of expression in which the reference takes place. For instance, (go x) means transfer control to label x, whereas (print x) refers to the variable x. Both scopes of x can be active in the same region of program text, since tagbody labels are in a separate namespace from variable names. A special form or macro form has complete control over the meanings of all symbols in its syntax. For instance, in (defclass x (a b) ()), a class definition, the (a b) is a list of base classes, so these names are looked up in the space of class names, and x isn't a reference to an existing binding, but the name of a new class being derived from a and b. These facts emerge purely from the semantics of defclass. The only generic fact about this expression is that defclass refers to a macro binding; everything else is up to defclass.Common Lisp_item_4_12
  • the location of the reference within the program text. For instance, if a reference to variable x is enclosed in a binding construct such as a let which defines a binding for x, then the reference is in the scope created by that binding.Common Lisp_item_4_13
  • for a variable reference, whether or not a variable symbol has been, locally or globally, declared special. This determines whether the reference is resolved within a lexical environment, or within a dynamic environment.Common Lisp_item_4_14
  • the specific instance of the environment in which the reference is resolved. An environment is a run-time dictionary which maps symbols to bindings. Each kind of reference uses its own kind of environment. References to lexical variables are resolved in a lexical environment, et cetera. More than one environment can be associated with the same reference. For instance, thanks to recursion or the use of multiple threads, multiple activations of the same function can exist at the same time. These activations share the same program text, but each has its own lexical environment instance.Common Lisp_item_4_15

To understand what a symbol refers to, the Common Lisp programmer must know what kind of reference is being expressed, what kind of scope it uses if it is a variable reference (dynamic versus lexical scope), and also the run-time situation: in what environment is the reference resolved, where was the binding introduced into the environment, et cetera. Common Lisp_sentence_130

Kinds of environment Common Lisp_section_13

Global Common Lisp_section_14

Some environments in Lisp are globally pervasive. Common Lisp_sentence_131

For instance, if a new type is defined, it is known everywhere thereafter. Common Lisp_sentence_132

References to that type look it up in this global environment. Common Lisp_sentence_133

Dynamic Common Lisp_section_15

One type of environment in Common Lisp is the dynamic environment. Common Lisp_sentence_134

Bindings established in this environment have dynamic extent, which means that a binding is established at the start of the execution of some construct, such as a let block, and disappears when that construct finishes executing: its lifetime is tied to the dynamic activation and deactivation of a block. Common Lisp_sentence_135

However, a dynamic binding is not just visible within that block; it is also visible to all functions invoked from that block. Common Lisp_sentence_136

This type of visibility is known as indefinite scope. Common Lisp_sentence_137

Bindings which exhibit dynamic extent (lifetime tied to the activation and deactivation of a block) and indefinite scope (visible to all functions which are called from that block) are said to have dynamic scope. Common Lisp_sentence_138

Common Lisp has support for dynamically scoped variables, which are also called special variables. Common Lisp_sentence_139

Certain other kinds of bindings are necessarily dynamically scoped also, such as restarts and catch tags. Common Lisp_sentence_140

Function bindings cannot be dynamically scoped using flet (which only provides lexically scoped function bindings), but function objects (a first-level object in Common Lisp) can be assigned to dynamically scoped variables, bound using let in dynamic scope, then called using funcall or APPLY. Common Lisp_sentence_141

Dynamic scope is extremely useful because it adds referential clarity and discipline to global variables. Common Lisp_sentence_142

Global variables are frowned upon in computer science as potential sources of error, because they can give rise to ad-hoc, covert channels of communication among modules that lead to unwanted, surprising interactions. Common Lisp_sentence_143

In Common Lisp, a special variable which has only a top-level binding behaves just like a global variable in other programming languages. Common Lisp_sentence_144

A new value can be stored into it, and that value simply replaces what is in the top-level binding. Common Lisp_sentence_145

Careless replacement of the value of a global variable is at the heart of bugs caused by the use of global variables. Common Lisp_sentence_146

However, another way to work with a special variable is to give it a new, local binding within an expression. Common Lisp_sentence_147

This is sometimes referred to as "rebinding" the variable. Common Lisp_sentence_148

Binding a dynamically scoped variable temporarily creates a new memory location for that variable, and associates the name with that location. Common Lisp_sentence_149

While that binding is in effect, all references to that variable refer to the new binding; the previous binding is hidden. Common Lisp_sentence_150

When execution of the binding expression terminates, the temporary memory location is gone, and the old binding is revealed, with the original value intact. Common Lisp_sentence_151

Of course, multiple dynamic bindings for the same variable can be nested. Common Lisp_sentence_152

In Common Lisp implementations which support multithreading, dynamic scopes are specific to each thread of execution. Common Lisp_sentence_153

Thus special variables serve as an abstraction for thread local storage. Common Lisp_sentence_154

If one thread rebinds a special variable, this rebinding has no effect on that variable in other threads. Common Lisp_sentence_155

The value stored in a binding can only be retrieved by the thread which created that binding. Common Lisp_sentence_156

If each thread binds some special variable *x*, then *x* behaves like thread-local storage. Common Lisp_sentence_157

Among threads which do not rebind *x*, it behaves like an ordinary global: all of these threads refer to the same top-level binding of *x*. Common Lisp_sentence_158

Dynamic variables can be used to extend the execution context with additional context information which is implicitly passed from function to function without having to appear as an extra function parameter. Common Lisp_sentence_159

This is especially useful when the control transfer has to pass through layers of unrelated code, which simply cannot be extended with extra parameters to pass the additional data. Common Lisp_sentence_160

A situation like this usually calls for a global variable. Common Lisp_sentence_161

That global variable must be saved and restored, so that the scheme doesn't break under recursion: dynamic variable rebinding takes care of this. Common Lisp_sentence_162

And that variable must be made thread-local (or else a big mutex must be used) so the scheme doesn't break under threads: dynamic scope implementations can take care of this also. Common Lisp_sentence_163

In the Common Lisp library, there are many standard special variables. Common Lisp_sentence_164

For instance, all standard I/O streams are stored in the top-level bindings of well-known special variables. Common Lisp_sentence_165

The standard output stream is stored in *standard-output*. Common Lisp_sentence_166

Suppose a function foo writes to standard output: Common Lisp_sentence_167

To capture its output in a character string, *standard-output* can be bound to a string stream and called: Common Lisp_sentence_168

Lexical Common Lisp_section_16

Common Lisp supports lexical environments. Common Lisp_sentence_169

Formally, the bindings in a lexical environment have lexical scope and may have either an indefinite extent or dynamic extent, depending on the type of namespace. Common Lisp_sentence_170

Lexical scope means that visibility is physically restricted to the block in which the binding is established. Common Lisp_sentence_171

References which are not textually (i.e. lexically) embedded in that block simply do not see that binding. Common Lisp_sentence_172

The tags in a TAGBODY have lexical scope. Common Lisp_sentence_173

The expression (GO X) is erroneous if it is not embedded in a TAGBODY which contains a label X. Common Lisp_sentence_174

However, the label bindings disappear when the TAGBODY terminates its execution, because they have dynamic extent. Common Lisp_sentence_175

If that block of code is re-entered by the invocation of a lexical closure, it is invalid for the body of that closure to try to transfer control to a tag via GO: Common Lisp_sentence_176

When the TAGBODY is executed, it first evaluates the setf form which stores a function in the special variable *stashed*. Common Lisp_sentence_177

Then the (go end-label) transfers control to end-label, skipping the code (print "Hello"). Common Lisp_sentence_178

Since end-label is at the end of the tagbody, the tagbody terminates, yielding NIL. Common Lisp_sentence_179

Suppose that the previously remembered function is now called: Common Lisp_sentence_180

This situation is erroneous. Common Lisp_sentence_181

One implementation's response is an error condition containing the message, "GO: tagbody for tag SOME-LABEL has already been left". Common Lisp_sentence_182

The function tried to evaluate (go some-label), which is lexically embedded in the tagbody, and resolves to the label. Common Lisp_sentence_183

However, the tagbody isn't executing (its extent has ended), and so the control transfer cannot take place. Common Lisp_sentence_184

Local function bindings in Lisp have lexical scope, and variable bindings also have lexical scope by default. Common Lisp_sentence_185

By contrast with GO labels, both of these have indefinite extent. Common Lisp_sentence_186

When a lexical function or variable binding is established, that binding continues to exist for as long as references to it are possible, even after the construct which established that binding has terminated. Common Lisp_sentence_187

References to lexical variables and functions after the termination of their establishing construct are possible thanks to lexical closures. Common Lisp_sentence_188

Lexical binding is the default binding mode for Common Lisp variables. Common Lisp_sentence_189

For an individual symbol, it can be switched to dynamic scope, either by a local declaration, by a global declaration. Common Lisp_sentence_190

The latter may occur implicitly through the use of a construct like DEFVAR or DEFPARAMETER. Common Lisp_sentence_191

It is an important convention in Common Lisp programming that special (i.e. dynamically scoped) variables have names which begin and end with an asterisk sigil * in what is called the "earmuff convention". Common Lisp_sentence_192

If adhered to, this convention effectively creates a separate namespace for special variables, so that variables intended to be lexical are not accidentally made special. Common Lisp_sentence_193

Lexical scope is useful for several reasons. Common Lisp_sentence_194

Firstly, references to variables and functions can be compiled to efficient machine code, because the run-time environment structure is relatively simple. Common Lisp_sentence_195

In many cases it can be optimized to stack storage, so opening and closing lexical scopes has minimal overhead. Common Lisp_sentence_196

Even in cases where full closures must be generated, access to the closure's environment is still efficient; typically each variable becomes an offset into a vector of bindings, and so a variable reference becomes a simple load or store instruction with a base-plus-offset addressing mode. Common Lisp_sentence_197

Secondly, lexical scope (combined with indefinite extent) gives rise to the lexical closure, which in turn creates a whole paradigm of programming centered around the use of functions being first-class objects, which is at the root of functional programming. Common Lisp_sentence_198

Thirdly, perhaps most importantly, even if lexical closures are not exploited, the use of lexical scope isolates program modules from unwanted interactions. Common Lisp_sentence_199

Due to their restricted visibility, lexical variables are private. Common Lisp_sentence_200

If one module A binds a lexical variable X, and calls another module B, references to X in B will not accidentally resolve to the X bound in A. Common Lisp_sentence_201

B simply has no access to X. Common Lisp_sentence_202

For situations in which disciplined interactions through a variable are desirable, Common Lisp provides special variables. Common Lisp_sentence_203

Special variables allow for a module A to set up a binding for a variable X which is visible to another module B, called from A. Common Lisp_sentence_204

Being able to do this is an advantage, and being able to prevent it from happening is also an advantage; consequently, Common Lisp supports both lexical and dynamic scope. Common Lisp_sentence_205

Macros Common Lisp_section_17

A macro in Lisp superficially resembles a function in usage. Common Lisp_sentence_206

However, rather than representing an expression which is evaluated, it represents a transformation of the program source code. Common Lisp_sentence_207

The macro gets the source it surrounds as arguments, binds them to its parameters and computes a new source form. Common Lisp_sentence_208

This new form can also use a macro. Common Lisp_sentence_209

The macro expansion is repeated until the new source form does not use a macro. Common Lisp_sentence_210

The final computed form is the source code executed at runtime. Common Lisp_sentence_211

Typical uses of macros in Lisp: Common Lisp_sentence_212

Common Lisp_unordered_list_5

  • new control structures (example: looping constructs, branching constructs)Common Lisp_item_5_16
  • scoping and binding constructsCommon Lisp_item_5_17
  • simplified syntax for complex and repeated source codeCommon Lisp_item_5_18
  • top-level defining forms with compile-time side-effectsCommon Lisp_item_5_19
  • data-driven programmingCommon Lisp_item_5_20
  • embedded domain specific languages (examples: SQL, HTML, Prolog)Common Lisp_item_5_21
  • implicit finalization formsCommon Lisp_item_5_22

Various standard Common Lisp features also need to be implemented as macros, such as: Common Lisp_sentence_213

Common Lisp_unordered_list_6

  • the standard setf abstraction, to allow custom compile-time expansions of assignment/access operatorsCommon Lisp_item_6_23
  • with-accessors, with-slots, with-open-file and other similar WITH macrosCommon Lisp_item_6_24
  • Depending on implementation, if or cond is a macro built on the other, the special operator; when and unless consist of macrosCommon Lisp_item_6_25
  • The powerful loop domain-specific languageCommon Lisp_item_6_26

Macros are defined by the defmacro macro. Common Lisp_sentence_214

The special operator macrolet allows the definition of local (lexically scoped) macros. Common Lisp_sentence_215

It is also possible to define macros for symbols using define-symbol-macro and symbol-macrolet. Common Lisp_sentence_216

Paul Graham's book On Lisp describes the use of macros in Common Lisp in detail. Common Lisp_sentence_217

Doug Hoyte's book Let Over Lambda extends the discussion on macros, claiming "Macros are the single greatest advantage that lisp has as a programming language and the single greatest advantage of any programming language." Common Lisp_sentence_218

Hoyte provides several examples of iterative development of macros. Common Lisp_sentence_219

Example using a macro to define a new control structure Common Lisp_section_18

Macros allow Lisp programmers to create new syntactic forms in the language. Common Lisp_sentence_220

One typical use is to create new control structures. Common Lisp_sentence_221

The example macro provides an until looping construct. Common Lisp_sentence_222

The syntax is: Common Lisp_sentence_223

The macro definition for until: Common Lisp_sentence_224

tagbody is a primitive Common Lisp special operator which provides the ability to name tags and use the go form to jump to those tags. Common Lisp_sentence_225

The backquote ` provides a notation that provides code templates, where the value of forms preceded with a comma are filled in. Common Lisp_sentence_226

Forms preceded with comma and at-sign are spliced in. Common Lisp_sentence_227

The tagbody form tests the end condition. Common Lisp_sentence_228

If the condition is true, it jumps to the end tag. Common Lisp_sentence_229

Otherwise the provided body code is executed and then it jumps to the start tag. Common Lisp_sentence_230

An example of using the above until macro: Common Lisp_sentence_231

The code can be expanded using the function macroexpand-1. Common Lisp_sentence_232

The expansion for above example looks like this: Common Lisp_sentence_233

During macro expansion the value of the variable test is (= (random 10) 0) and the value of the variable body is ((write-line "Hello")). Common Lisp_sentence_234

The body is a list of forms. Common Lisp_sentence_235

Symbols are usually automatically upcased. Common Lisp_sentence_236

The expansion uses the TAGBODY with two labels. Common Lisp_sentence_237

The symbols for these labels are computed by GENSYM and are not interned in any package. Common Lisp_sentence_238

Two go forms use these tags to jump to. Common Lisp_sentence_239

Since tagbody is a primitive operator in Common Lisp (and not a macro), it will not be expanded into something else. Common Lisp_sentence_240

The expanded form uses the when macro, which also will be expanded. Common Lisp_sentence_241

Fully expanding a source form is called code walking. Common Lisp_sentence_242

In the fully expanded (walked) form, the when form is replaced by the primitive if: Common Lisp_sentence_243

All macros must be expanded before the source code containing them can be evaluated or compiled normally. Common Lisp_sentence_244

Macros can be considered functions that accept and return S-expressions – similar to abstract syntax trees, but not limited to those. Common Lisp_sentence_245

These functions are invoked before the evaluator or compiler to produce the final source code. Common Lisp_sentence_246

Macros are written in normal Common Lisp, and may use any Common Lisp (or third-party) operator available. Common Lisp_sentence_247

Variable capture and shadowing Common Lisp_section_19

Common Lisp macros are capable of what is commonly called variable capture, where symbols in the macro-expansion body coincide with those in the calling context, allowing the programmer to create macros wherein various symbols have special meaning. Common Lisp_sentence_248

The term variable capture is somewhat misleading, because all namespaces are vulnerable to unwanted capture, including the operator and function namespace, the tagbody label namespace, catch tag, condition handler and restart namespaces. Common Lisp_sentence_249

Variable capture can introduce software defects. Common Lisp_sentence_250

This happens in one of the following two ways: Common Lisp_sentence_251

Common Lisp_unordered_list_7

  • In the first way, a macro expansion can inadvertently make a symbolic reference which the macro writer assumed will resolve in a global namespace, but the code where the macro is expanded happens to provide a local, shadowing definition which steals that reference. Let this be referred to as type 1 capture.Common Lisp_item_7_27
  • The second way, type 2 capture, is just the opposite: some of the arguments of the macro are pieces of code supplied by the macro caller, and those pieces of code are written such that they make references to surrounding bindings. However, the macro inserts these pieces of code into an expansion which defines its own bindings that accidentally captures some of these references.Common Lisp_item_7_28

The Scheme dialect of Lisp provides a macro-writing system which provides the referential transparency that eliminates both types of capture problem. Common Lisp_sentence_252

This type of macro system is sometimes called "hygienic", in particular by its proponents (who regard macro systems which do not automatically solve this problem as unhygienic). Common Lisp_sentence_253

In Common Lisp, macro hygiene is ensured one of two different ways. Common Lisp_sentence_254

One approach is to use gensyms: guaranteed-unique symbols which can be used in a macro-expansion without threat of capture. Common Lisp_sentence_255

The use of gensyms in a macro definition is a manual chore, but macros can be written which simplify the instantiation and use of gensyms. Common Lisp_sentence_256

Gensyms solve type 2 capture easily, but they are not applicable to type 1 capture in the same way, because the macro expansion cannot rename the interfering symbols in the surrounding code which capture its references. Common Lisp_sentence_257

Gensyms could be used to provide stable aliases for the global symbols which the macro expansion needs. Common Lisp_sentence_258

The macro expansion would use these secret aliases rather than the well-known names, so redefinition of the well-known names would have no ill effect on the macro. Common Lisp_sentence_259

Another approach is to use packages. Common Lisp_sentence_260

A macro defined in its own package can simply use internal symbols in that package in its expansion. Common Lisp_sentence_261

The use of packages deals with type 1 and type 2 capture. Common Lisp_sentence_262

However, packages don't solve the type 1 capture of references to standard Common Lisp functions and operators. Common Lisp_sentence_263

The reason is that the use of packages to solve capture problems revolves around the use of private symbols (symbols in one package, which are not imported into, or otherwise made visible in other packages). Common Lisp_sentence_264

Whereas the Common Lisp library symbols are external, and frequently imported into or made visible in user-defined packages. Common Lisp_sentence_265

The following is an example of unwanted capture in the operator namespace, occurring in the expansion of a macro: Common Lisp_sentence_266

The until macro will expand into a form which calls do which is intended to refer to the standard Common Lisp macro do. Common Lisp_sentence_267

However, in this context, do may have a completely different meaning, so until may not work properly. Common Lisp_sentence_268

Common Lisp solves the problem of the shadowing of standard operators and functions by forbidding their redefinition. Common Lisp_sentence_269

Because it redefines the standard operator do, the preceding is actually a fragment of non-conforming Common Lisp, which allows implementations to diagnose and reject it. Common Lisp_sentence_270

Condition system Common Lisp_section_20

The condition system is responsible for exception handling in Common Lisp. Common Lisp_sentence_271

It provides conditions, handlers and restarts. Common Lisp_sentence_272

Conditions are objects describing an exceptional situation (for example an error). Common Lisp_sentence_273

If a condition is signaled, the Common Lisp system searches for a handler for this condition type and calls the handler. Common Lisp_sentence_274

The handler can now search for restarts and use one of these restarts to automatically repair the current problem, using information such as the condition type and any relevant information provided as part of the condition object, and call the appropriate restart function. Common Lisp_sentence_275

These restarts, if unhandled by code, can be presented to users (as part of a user interface, that of a debugger for example), so that the user can select and invoke one of the available restarts. Common Lisp_sentence_276

Since the condition handler is called in the context of the error (without unwinding the stack), full error recovery is possible in many cases, where other exception handling systems would have already terminated the current routine. Common Lisp_sentence_277

The debugger itself can also be customized or replaced using the *debugger-hook* dynamic variable. Common Lisp_sentence_278

Code found within unwind-protect forms such as finalizers will also be executed as appropriate despite the exception. Common Lisp_sentence_279

In the following example (using Symbolics Genera) the user tries to open a file in a Lisp function test called from the Read-Eval-Print-LOOP (REPL), when the file does not exist. Common Lisp_sentence_280

The Lisp system presents four restarts. Common Lisp_sentence_281

The user selects the Retry OPEN using a different pathname restart and enters a different pathname (lispm-init.lisp instead of lispm-int.lisp). Common Lisp_sentence_282

The user code does not contain any error handling code. Common Lisp_sentence_283

The whole error handling and restart code is provided by the Lisp system, which can handle and repair the error without terminating the user code. Common Lisp_sentence_284

Common Lisp Object System (CLOS) Common Lisp_section_21

Main article: Common Lisp Object System Common Lisp_sentence_285

Common Lisp includes a toolkit for object-oriented programming, the Common Lisp Object System or CLOS, which is one of the most powerful object systems available in any language. Common Lisp_sentence_286

For example, Peter Norvig explains how many Design Patterns are simpler to implement in a dynamic language with the features of CLOS (Multiple Inheritance, Mixins, Multimethods, Metaclasses, Method combinations, etc.). Common Lisp_sentence_287

Several extensions to Common Lisp for object-oriented programming have been proposed to be included into the ANSI Common Lisp standard, but eventually CLOS was adopted as the standard object-system for Common Lisp. Common Lisp_sentence_288

CLOS is a dynamic object system with multiple dispatch and multiple inheritance, and differs radically from the OOP facilities found in static languages such as C++ or Java. Common Lisp_sentence_289

As a dynamic object system, CLOS allows changes at runtime to generic functions and classes. Common Lisp_sentence_290

Methods can be added and removed, classes can be added and redefined, objects can be updated for class changes and the class of objects can be changed. Common Lisp_sentence_291

CLOS has been integrated into ANSI Common Lisp. Common Lisp_sentence_292

Generic functions can be used like normal functions and are a first-class data type. Common Lisp_sentence_293

Every CLOS class is integrated into the Common Lisp type system. Common Lisp_sentence_294

Many Common Lisp types have a corresponding class. Common Lisp_sentence_295

There is more potential use of CLOS for Common Lisp. Common Lisp_sentence_296

The specification does not say whether conditions are implemented with CLOS. Common Lisp_sentence_297

Pathnames and streams could be implemented with CLOS. Common Lisp_sentence_298

These further usage possibilities of CLOS for ANSI Common Lisp are not part of the standard. Common Lisp_sentence_299

Actual Common Lisp implementations use CLOS for pathnames, streams, input–output, conditions, the implementation of CLOS itself and more. Common Lisp_sentence_300

Compiler and interpreter Common Lisp_section_22

A Lisp interpreter directly executes Lisp source code provided as Lisp objects (lists, symbols, numbers, ...) read from s-expressions. Common Lisp_sentence_301

A Lisp compiler generates bytecode or machine code from Lisp source code. Common Lisp_sentence_302

Common Lisp allows both individual Lisp functions to be compiled in memory and the compilation of whole files to externally stored compiled code (fasl files). Common Lisp_sentence_303

Several implementations of earlier Lisp dialects provided both an interpreter and a compiler. Common Lisp_sentence_304

Unfortunately often the semantics were different. Common Lisp_sentence_305

These earlier Lisps implemented lexical scoping in the compiler and dynamic scoping in the interpreter. Common Lisp_sentence_306

Common Lisp requires that both the interpreter and compiler use lexical scoping by default. Common Lisp_sentence_307

The Common Lisp standard describes both the semantics of the interpreter and a compiler. Common Lisp_sentence_308

The compiler can be called using the function compile for individual functions and using the function compile-file for files. Common Lisp_sentence_309

Common Lisp allows type declarations and provides ways to influence the compiler code generation policy. Common Lisp_sentence_310

For the latter various optimization qualities can be given values between 0 (not important) and 3 (most important): speed, space, safety, debug and compilation-speed. Common Lisp_sentence_311

There is also a function to evaluate Lisp code: eval. Common Lisp_sentence_312

eval takes code as pre-parsed s-expressions and not, like in some other languages, as text strings. Common Lisp_sentence_313

This way code can be constructed with the usual Lisp functions for constructing lists and symbols and then this code can be evaluated with the function eval. Common Lisp_sentence_314

Several Common Lisp implementations (like Clozure CL and SBCL) are implementing eval using their compiler. Common Lisp_sentence_315

This way code is compiled, even though it is evaluated using the function eval. Common Lisp_sentence_316

The file compiler is invoked using the function compile-file. Common Lisp_sentence_317

The generated file with compiled code is called a fasl (from fast load) file. Common Lisp_sentence_318

These fasl files and also source code files can be loaded with the function load into a running Common Lisp system. Common Lisp_sentence_319

Depending on the implementation, the file compiler generates byte-code (for example for the Java Virtual Machine), C language code (which then is compiled with a C compiler) or, directly, native code. Common Lisp_sentence_320

Common Lisp implementations can be used interactively, even though the code gets fully compiled. Common Lisp_sentence_321

The idea of an Interpreted language thus does not apply for interactive Common Lisp. Common Lisp_sentence_322

The language makes a distinction between read-time, compile-time, load-time, and run-time, and allows user code to also make this distinction to perform the wanted type of processing at the wanted step. Common Lisp_sentence_323

Some special operators are provided to especially suit interactive development; for instance, defvar will only assign a value to its provided variable if it wasn't already bound, while defparameter will always perform the assignment. Common Lisp_sentence_324

This distinction is useful when interactively evaluating, compiling and loading code in a live image. Common Lisp_sentence_325

Some features are also provided to help writing compilers and interpreters. Common Lisp_sentence_326

Symbols consist of first-level objects and are directly manipulable by user code. Common Lisp_sentence_327

The progv special operator allows to create lexical bindings programmatically, while packages are also manipulable. Common Lisp_sentence_328

The Lisp compiler is available at runtime to compile files or individual functions. Common Lisp_sentence_329

These make it easy to use Lisp as an intermediate compiler or interpreter for another language. Common Lisp_sentence_330

Code examples Common Lisp_section_23

Birthday paradox Common Lisp_section_24

The following program calculates the smallest number of people in a room for whom the probability of unique birthdays is less than 50% (the birthday paradox, where for 1 person the probability is obviously 100%, for 2 it is 364/365, etc.). Common Lisp_sentence_331

The answer is 23. Common Lisp_sentence_332

By convention, constants in Common Lisp are enclosed with + characters. Common Lisp_sentence_333

Calling the example function using the REPL (Read Eval Print Loop): Common Lisp_sentence_334

Sorting a list of person objects Common Lisp_section_25

We define a class person and a method for displaying the name and age of a person. Common Lisp_sentence_335

Next we define a group of persons as a list of person objects. Common Lisp_sentence_336

Then we iterate over the sorted list. Common Lisp_sentence_337

It prints the three names with descending age. Common Lisp_sentence_338

Exponentiating by squaring Common Lisp_section_26

Use of the LOOP macro is demonstrated: Common Lisp_sentence_339

Example use: Common Lisp_sentence_340

Compare with the built in exponentiation: Common Lisp_sentence_341

Find the list of available shells Common Lisp_section_27

WITH-OPEN-FILE is a macro that opens a file and provides a stream. Common Lisp_sentence_342

When the form is returning, the file is automatically closed. Common Lisp_sentence_343

FUNCALL calls a function object. Common Lisp_sentence_344

The LOOP collects all lines that match the predicate. Common Lisp_sentence_345

The function AVAILABLE-SHELLS calls above function LIST-MATCHING-LINES with a pathname and an anonymous function as the predicate. Common Lisp_sentence_346

The predicate returns the pathname of a shell or NIL (if the string is not the filename of a shell). Common Lisp_sentence_347

Example results (on Mac OS X 10.6): Common Lisp_sentence_348

Comparison with other Lisps Common Lisp_section_28

Common Lisp is most frequently compared with, and contrasted to, Scheme—if only because they are the two most popular Lisp dialects. Common Lisp_sentence_349

Scheme predates CL, and comes not only from the same Lisp tradition but from some of the same engineers—Guy L. Steele, with whom Gerald Jay Sussman designed Scheme, chaired the standards committee for Common Lisp. Common Lisp_sentence_350

Common Lisp is a general-purpose programming language, in contrast to Lisp variants such as Emacs Lisp and AutoLISP which are extension languages embedded in particular products (GNU Emacs and AutoCAD, respectively). Common Lisp_sentence_351

Unlike many earlier Lisps, Common Lisp (like Scheme) uses lexical variable scope by default for both interpreted and compiled code. Common Lisp_sentence_352

Most of the Lisp systems whose designs contributed to Common Lisp—such as ZetaLisp and Franz Lisp—used dynamically scoped variables in their interpreters and lexically scoped variables in their compilers. Common Lisp_sentence_353

Scheme introduced the sole use of lexically scoped variables to Lisp; an inspiration from ALGOL 68. Common Lisp_sentence_354

CL supports dynamically scoped variables as well, but they must be explicitly declared as "special". Common Lisp_sentence_355

There are no differences in scoping between ANSI CL interpreters and compilers. Common Lisp_sentence_356

Common Lisp is sometimes termed a Lisp-2 and Scheme a Lisp-1, referring to CL's use of separate namespaces for functions and variables. Common Lisp_sentence_357

(In fact, CL has many namespaces, such as those for go tags, block names, and loop keywords). Common Lisp_sentence_358

There is a long-standing controversy between CL and Scheme advocates over the tradeoffs involved in multiple namespaces. Common Lisp_sentence_359

In Scheme, it is (broadly) necessary to avoid giving variables names which clash with functions; Scheme functions frequently have arguments named lis, lst, or lyst so as not to conflict with the system function list. Common Lisp_sentence_360

However, in CL it is necessary to explicitly refer to the function namespace when passing a function as an argument—which is also a common occurrence, as in the sort example above. Common Lisp_sentence_361

CL also differs from Scheme in its handling of boolean values. Common Lisp_sentence_362

Scheme uses the special values #t and #f to represent truth and falsity. Common Lisp_sentence_363

CL follows the older Lisp convention of using the symbols T and NIL, with NIL standing also for the empty list. Common Lisp_sentence_364

In CL, any non-NIL value is treated as true by conditionals, such as if, whereas in Scheme all non-#f values are treated as true. Common Lisp_sentence_365

These conventions allow some operators in both languages to serve both as predicates (answering a boolean-valued question) and as returning a useful value for further computation, but in Scheme the value '() which is equivalent to NIL in Common Lisp evaluates to true in a boolean expression. Common Lisp_sentence_366

Lastly, the Scheme standards documents require tail-call optimization, which the CL standard does not. Common Lisp_sentence_367

Most CL implementations do offer tail-call optimization, although often only when the programmer uses an optimization directive. Common Lisp_sentence_368

Nonetheless, common CL coding style does not favor the ubiquitous use of recursion that Scheme style prefers—what a Scheme programmer would express with tail recursion, a CL user would usually express with an iterative expression in do, dolist, loop, or (more recently) with the iterate package. Common Lisp_sentence_369

Implementations Common Lisp_section_29

See the Category Common Lisp implementations. Common Lisp_sentence_370

Common Lisp is defined by a specification (like Ada and C) rather than by one implementation (like Perl). Common Lisp_sentence_371

There are many implementations, and the standard details areas in which they may validly differ. Common Lisp_sentence_372

In addition, implementations tend to come with extensions, which provide functionality not covered in the standard: Common Lisp_sentence_373

Common Lisp_unordered_list_8

  • Interactive Top-Level (REPL)Common Lisp_item_8_29
  • Garbage CollectionCommon Lisp_item_8_30
  • Debugger, Stepper and InspectorCommon Lisp_item_8_31
  • Weak data structures (hash tables)Common Lisp_item_8_32
  • Extensible sequencesCommon Lisp_item_8_33
  • Extensible LOOPCommon Lisp_item_8_34
  • Environment accessCommon Lisp_item_8_35
  • CLOS Meta-object ProtocolCommon Lisp_item_8_36
  • CLOS based extensible streamsCommon Lisp_item_8_37
  • CLOS based Condition SystemCommon Lisp_item_8_38
  • Network streamsCommon Lisp_item_8_39
  • Persistent CLOSCommon Lisp_item_8_40
  • Unicode supportCommon Lisp_item_8_41
  • Foreign-Language Interface (often to C)Common Lisp_item_8_42
  • Operating System interfaceCommon Lisp_item_8_43
  • Java InterfaceCommon Lisp_item_8_44
  • Threads and MultiprocessingCommon Lisp_item_8_45
  • Application delivery (applications, dynamic libraries)Common Lisp_item_8_46
  • Saving of imagesCommon Lisp_item_8_47

Free and open-source software libraries have been created to support extensions to Common Lisp in a portable way, and are most notably found in the repositories of the and CLOCC (Common Lisp Open Code Collection) projects. Common Lisp_sentence_374

Common Lisp implementations may use any mix of native code compilation, byte code compilation or interpretation. Common Lisp_sentence_375

Common Lisp has been designed to support incremental compilers, file compilers and block compilers. Common Lisp_sentence_376

Standard declarations to optimize compilation (such as function inlining or type specialization) are proposed in the language specification. Common Lisp_sentence_377

Most Common Lisp implementations compile source code to native machine code. Common Lisp_sentence_378

Some implementations can create (optimized) stand-alone applications. Common Lisp_sentence_379

Others compile to interpreted bytecode, which is less efficient than native code, but eases binary-code portability. Common Lisp_sentence_380

Some compilers compile Common Lisp code to C code. Common Lisp_sentence_381

The misconception that Lisp is a purely interpreted language is most likely because Lisp environments provide an interactive prompt and that code is compiled one-by-one, in an incremental way. Common Lisp_sentence_382

With Common Lisp incremental compilation is widely used. Common Lisp_sentence_383

Some Unix-based implementations (CLISP, SBCL) can be used as a scripting language; that is, invoked by the system transparently in the way that a Perl or Unix shell interpreter is. Common Lisp_sentence_384

List of implementations Common Lisp_section_30

Commercial implementations Common Lisp_section_31

Common Lisp_description_list_9

Freely redistributable implementations Common Lisp_section_32

Common Lisp_description_list_10

  • Armed Bear Common Lisp (ABCL): A CL implementation that runs on the Java Virtual Machine. It includes a compiler to Java byte code, and allows access to Java libraries from CL. It was formerly just a component of the Armed Bear J Editor.Common Lisp_item_10_54
  • CLISP: A bytecode-compiling implementation, portable and runs on several Unix and Unix-like systems (including macOS), as well as Microsoft Windows and several other systems.Common Lisp_item_10_55
  • Clozure CL (CCL): Originally a free and open-source fork of Macintosh Common Lisp. As that history implies, CCL was written for the Macintosh, but Clozure CL now runs on macOS, FreeBSD, Linux, Solaris and Windows. 32 and 64 bit x86 ports are supported on each platform. Additionally there are Power PC ports for Mac OS and Linux. CCL was previously known as OpenMCL, but that name is no longer used, to avoid confusion with the open source version of Macintosh Common Lisp.Common Lisp_item_10_56
  • CMUCL: Originally from Carnegie Mellon University, now maintained as free and open-source software by a group of volunteers. CMUCL uses a fast native-code compiler. It is available on Linux and BSD for Intel x86; Linux for Alpha; macOS for Intel x86 and PowerPC; and Solaris, IRIX, and HP-UX on their native platforms.Common Lisp_item_10_57
  • Corman Common Lisp: for Microsoft Windows. In January 2015 Corman Lisp has been published under MIT license.Common Lisp_item_10_58
  • Embeddable Common Lisp (ECL): ECL includes a bytecode interpreter and compiler. It can also compile Lisp code to machine code via a C compiler. ECL then compiles Lisp code to C, compiles the C code with a C compiler and can then load the resulting machine code. It is also possible to embed ECL in C programs, and C code into Common Lisp programs.Common Lisp_item_10_59
  • GNU Common Lisp (GCL): The GNU Project's Lisp compiler. Not yet fully ANSI-compliant, GCL is however the implementation of choice for several large projects including the mathematical tools Maxima, AXIOM and (historically) ACL2. GCL runs on Linux under eleven different architectures, and also under Windows, Solaris, and FreeBSD.Common Lisp_item_10_60
  • Macintosh Common Lisp (MCL): Version 5.2 for Apple Macintosh computers with a PowerPC processor running Mac OS X is open source. RMCL (based on MCL 5.2) runs on Intel-based Apple Macintosh computers using the Rosetta binary translator from Apple.Common Lisp_item_10_61
  • ManKai Common Lisp (MKCL): A branch of ECL. MKCL emphasises reliability, stability and overall code quality through a heavily reworked, natively multi-threaded, runtime system. On Linux, MKCL features a fully POSIX compliant runtime system.Common Lisp_item_10_62
  • Movitz: Implements a Lisp environment for x86 computers without relying on any underlying OS.Common Lisp_item_10_63
  • Poplog: Poplog implements a version of CL, with POP-11, and optionally Prolog, and Standard ML (SML), allowing mixed language programming. For all, the implementation language is POP-11, which is compiled incrementally. It also has an integrated Emacs-like editor that communicates with the compiler.Common Lisp_item_10_64
  • Steel Bank Common Lisp (SBCL): A branch from CMUCL. "Broadly speaking, SBCL is distinguished from CMU CL by a greater emphasis on maintainability." SBCL runs on the platforms CMUCL does, except HP/UX; in addition, it runs on Linux for AMD64, PowerPC, SPARC, MIPS, Windows x86 and has experimental support for running on Windows AMD64. SBCL does not use an interpreter by default; all expressions are compiled to native code unless the user switches the interpreter on. The SBCL compiler generates fast native code according to a previous version of The Computer Language Benchmarks Game.Common Lisp_item_10_65
  • Ufasoft Common Lisp: port of CLISP for windows platform with core written in C++.Common Lisp_item_10_66

Other implementations Common Lisp_section_33

Credits to the contents of this page go to the authors of the corresponding Wikipedia page: Lisp.