text:
Common Lisp

Common Lisp (CL) is a dialect of the Lisp programming language, published in American National Standards Institute (ANSI) standard document ANSI INCITS 226-1994 (S2018) (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,  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 of safety level is wanted, using optimize declarations.

Common Lisp includes CLOS, an object system that supports multimethods and method combinations. It is often implemented with a Metaobject Protocol.

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

Common Lisp provides partial backwards compatibility with Maclisp and John McCarthy's original Lisp. This allows older Lisp software to be ported to Common Lisp.

History
Work on Common Lisp started in 1981 after an initiative by ARPA manager Bob Engelmore to develop a single community standard Lisp dialect. Much of the initial language design was done via electronic mail. In 1982, Guy L. Steele Jr. gave the first overview of Common Lisp at the 1982 ACM Symposium on LISP and functional programming.

The first language documentation was published in 1984 as Common Lisp the Language (known as CLtL1), first edition. 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. But CLtL2 does not describe the final ANSI Common Lisp standard and thus is not a documentation of ANSI Common Lisp. The final ANSI Common Lisp standard then was published in 1994. Since then no update to the standard has been published. Various extensions and improvements to Common Lisp (examples are Unicode, Concurrency, CLOS-based IO) have been provided by implementations and libraries.

Syntax
Common Lisp is a dialect of Lisp. It uses S-expressions to denote both code and data structure. Function calls, macro forms and special forms are written as lists, with the name of the operator first, as in these examples:

Data types
Common Lisp has many data types.

Scalar types
Number types include integers, ratios, floating-point numbers, and complex numbers. Common Lisp uses bignums to represent numerical values of arbitrary size and precision. The ratio type represents fractions exactly, a facility not available in many languages. Common Lisp automatically coerces numeric values among these types as appropriate.

The Common Lisp character type is not limited to ASCII characters. Most modern implementations allow Unicode characters.

The symbol type is common to Lisp languages, but largely unknown outside them. A symbol is a unique, named data object with several parts: name, value, function, property list, and package. Of these, value cell and function cell are the most important. 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. Normally, when a symbol is evaluated, its value is returned. Some symbols evaluate to themselves, for example, all symbols in the keyword package are self-evaluating. Boolean values in Common Lisp are represented by the self-evaluating symbols T and NIL. Common Lisp has namespaces for symbols, called 'packages'.

A number of functions are available for rounding scalar numeric values in various ways. The function  rounds the argument to the nearest integer, with halfway cases rounded to the even integer. The functions,  , and   round towards zero, down, or up respectively. All these functions return the discarded fractional part as a secondary value. For example,  yields −3, 0.5;   yields −2, −0.5;   yields 2, 0.5; and   yields 4, −0.5.

Data structures
Sequence types in Common Lisp include lists, vectors, bit-vectors, and strings. There are many operations that can work on any sequence type.

As in almost all other Lisp dialects, lists in Common Lisp are composed of conses, sometimes called cons cells or pairs. A cons is a data structure with two slots, called its car and cdr. A list is a linked chain of conses or the empty list. Each cons's car refers to a member of the list (possibly another list). Each cons's cdr refers to the next cons—except for the last cons in a list, whose cdr refers to the  value. 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. It is also possible to create circular data structures with conses.

Common Lisp supports multidimensional arrays, and can dynamically resize adjustable arrays if required. Multidimensional arrays can be used for matrix mathematics. A vector is a one-dimensional array. 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. Usually, only a few types are supported. Many implementations can optimize array functions when the array used is type-specialized. Two type-specialized array types are standard: a string is a vector of characters, while a bit-vector is a vector of bits.

Hash tables store associations between data objects. Any object may be used as key or value. Hash tables are automatically resized as needed.

Packages are collections of symbols, used chiefly to separate the parts of a program into namespaces. A package may export some symbols, marking them as part of a public interface. Packages can use other packages.

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

Classes are similar to structures, but offer more dynamic features and multiple-inheritance. (See CLOS). Classes have been added late to Common Lisp and there is some conceptual overlap with structures. Objects created of classes are called Instances. A special case is Generic Functions. Generic Functions are both functions and instances.

Functions
Common Lisp supports first-class functions. For instance, it is possible to write functions that take other functions as arguments or return functions as well. This makes it possible to describe very general operations.

The Common Lisp library relies heavily on such higher-order functions. For example, the  function takes a relational operator as an argument and key function as an optional keyword argument. This can be used not only to sort any type of data, but also to sort data structures according to a key.

The evaluation model for functions is very simple. When the evaluator encounters a form  then it presumes that the symbol named f is one of the following:

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

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.

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

Function definitions may include compiler directives, known as declarations, which provide hints to the compiler about optimization settings or the data types of arguments. They may also include documentation strings (docstrings), which the Lisp system may use to provide interactive documentation:

Anonymous functions (function literals) are defined using  expressions, e.g.   for a function that squares its argument. Lisp programming style frequently uses higher-order functions for which it is useful to provide anonymous functions as arguments.

Local functions can be defined with  and.

There are several other operators related to the definition and manipulation of functions. For instance, a function may be compiled with the  operator. (Some Lisp systems run functions using an interpreter by default unless instructed to compile; others compile every function).

Defining generic functions and methods
The macro  defines generic functions. Generic functions are a collection of methods. The macro  defines methods.

Methods can specialize their parameters over CLOS standard classes, system classes, structure classes or individual objects. For many types, there are corresponding system classes.

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

Generic Functions are also a first class data type. There are many more features to Generic Functions and Methods than described above.

The function namespace
The namespace for function names is separate from the namespace for data variables. This is a key difference between Common Lisp and Scheme. For Common Lisp, operators that define names in the function namespace include,  ,  ,   and.

To pass a function by name as an argument to another function, one must use the  special operator, commonly abbreviated as. The first  example above refers to the function named by the symbol   in the function namespace, with the code. Conversely, to call a function passed in such a way, one would use the  operator on the argument.

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. Code written in one dialect is therefore sometimes confusing to programmers more experienced in the other. 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.

Whether a separate namespace for functions is an advantage is a source of contention in the Lisp community. It is usually referred to as the Lisp-1 vs. Lisp-2 debate. Lisp-1 refers to Scheme's model and Lisp-2 refers to Common Lisp's model. These names were coined in a 1988 paper by Richard P. Gabriel and Kent Pitman, which extensively compares the two approaches.

Multiple return values
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. This concept is distinct from returning a list value, as the secondary values are fully optional, and passed via a dedicated side channel. 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. For example,

 * The  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:

 * 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.

Multiple values are supported by a handful of standard forms, most common of which are the  special form for accessing secondary values and   for returning multiple values:

Other types
Other data types in Common Lisp include:

 * Pathnames represent files and directories in the filesystem. 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.
 * Input and output streams represent sources and sinks of binary or textual data, such as the terminal or open files.
 * 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.
 * Conditions are a type used to represent errors, exceptions, and other "interesting" events to which a program may respond.
 * Classes are first-class objects, and are themselves instances of classes called metaobject classes (metaclasses for short).
 * 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.

Scope
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. Named references are subject to scope.

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

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

Determiners of scope
The circumstances which determine scope in Common Lisp include:

 * 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.
 * the kind of expression in which the reference takes place. For instance,  means transfer control to label , whereas   refers to the variable  . Both scopes of   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  , a class definition, the   is a list of base classes, so these names are looked up in the space of class names, and   isn't a reference to an existing binding, but the name of a new class being derived from   and  . These facts emerge purely from the semantics of  . The only generic fact about this expression is that   refers to a macro binding; everything else is up to.
 * the location of the reference within the program text. For instance, if a reference to variable  is enclosed in a binding construct such as a   which defines a binding for , then the reference is in the scope created by that binding.
 * 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.
 * 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.

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.

Global
Some environments in Lisp are globally pervasive. For instance, if a new type is defined, it is known everywhere thereafter. References to that type look it up in this global environment.

Dynamic
One type of environment in Common Lisp is the dynamic environment. 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  block, and disappears when that construct finishes executing: its lifetime is tied to the dynamic activation and deactivation of a block. However, a dynamic binding is not just visible within that block; it is also visible to all functions invoked from that block. This type of visibility is known as indefinite scope. 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 has support for dynamically scoped variables, which are also called special variables. Certain other kinds of bindings are necessarily dynamically scoped also, such as restarts and catch tags. Function bindings cannot be dynamically scoped using  (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   in dynamic scope, then called using   or.

Dynamic scope is extremely useful because it adds referential clarity and discipline to global variables. 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.

In Common Lisp, a special variable which has only a top-level binding behaves just like a global variable in other programming languages. A new value can be stored into it, and that value simply replaces what is in the top-level binding. Careless replacement of the value of a global variable is at the heart of bugs caused by the use of global variables. However, another way to work with a special variable is to give it a new, local binding within an expression. This is sometimes referred to as "rebinding" the variable. Binding a dynamically scoped variable temporarily creates a new memory location for that variable, and associates the name with that location. While that binding is in effect, all references to that variable refer to the new binding; the previous binding is hidden. When execution of the binding expression terminates, the temporary memory location is gone, and the old binding is revealed, with the original value intact. Of course, multiple dynamic bindings for the same variable can be nested.

In Common Lisp implementations which support multithreading, dynamic scopes are specific to each thread of execution. Thus special variables serve as an abstraction for thread local storage. If one thread rebinds a special variable, this rebinding has no effect on that variable in other threads. The value stored in a binding can only be retrieved by the thread which created that binding. If each thread binds some special variable, then   behaves like thread-local storage. Among threads which do not rebind, it behaves like an ordinary global: all of these threads refer to the same top-level binding of.

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. 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. A situation like this usually calls for a global variable. That global variable must be saved and restored, so that the scheme doesn't break under recursion: dynamic variable rebinding takes care of this. 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.

In the Common Lisp library, there are many standard special variables. For instance, all standard I/O streams are stored in the top-level bindings of well-known special variables. The standard output stream is stored in *standard-output*.

Suppose a function foo writes to standard output:

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

-> "Hello, world" ; gathered output returned as a string

Lexical
Common Lisp supports lexical environments. 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. Lexical scope means that visibility is physically restricted to the block in which the binding is established. References which are not textually (i.e. lexically) embedded in that block simply do not see that binding.

The tags in a TAGBODY have lexical scope. The expression (GO X) is erroneous if it is not embedded in a TAGBODY which contains a label X. However, the label bindings disappear when the TAGBODY terminates its execution, because they have dynamic extent. 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:

When the TAGBODY is executed, it first evaluates the setf form which stores a function in the special variable *stashed*. Then the (go end-label) transfers control to end-label, skipping the code (print "Hello"). Since end-label is at the end of the tagbody, the tagbody terminates, yielding NIL. Suppose that the previously remembered function is now called:

This situation is erroneous. One implementation's response is an error condition containing the message, "GO: tagbody for tag SOME-LABEL has already been left". The function tried to evaluate (go some-label), which is lexically embedded in the tagbody, and resolves to the label. However, the tagbody isn't executing (its extent has ended), and so the control transfer cannot take place.

Local function bindings in Lisp have lexical scope, and variable bindings also have lexical scope by default. By contrast with GO labels, both of these have indefinite extent. 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. References to lexical variables and functions after the termination of their establishing construct are possible thanks to lexical closures.

Lexical binding is the default binding mode for Common Lisp variables. For an individual symbol, it can be switched to dynamic scope, either by a local declaration, by a global declaration. The latter may occur implicitly through the use of a construct like DEFVAR or DEFPARAMETER. 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". 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.

Lexical scope is useful for several reasons.

Firstly, references to variables and functions can be compiled to efficient machine code, because the run-time environment structure is relatively simple. In many cases it can be optimized to stack storage, so opening and closing lexical scopes has minimal overhead. 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.

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.

Thirdly, perhaps most importantly, even if lexical closures are not exploited, the use of lexical scope isolates program modules from unwanted interactions. Due to their restricted visibility, lexical variables are private. 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. B simply has no access to X. For situations in which disciplined interactions through a variable are desirable, Common Lisp provides special variables. 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. 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.

Macros
A macro in Lisp superficially resembles a function in usage. However, rather than representing an expression which is evaluated, it represents a transformation of the program source code. The macro gets the source it surrounds as arguments, binds them to its parameters and computes a new source form. This new form can also use a macro. The macro expansion is repeated until the new source form does not use a macro. The final computed form is the source code executed at runtime.

Typical uses of macros in Lisp:

 * new control structures (example: looping constructs, branching constructs)
 * scoping and binding constructs
 * simplified syntax for complex and repeated source code
 * top-level defining forms with compile-time side-effects
 * data-driven programming
 * embedded domain specific languages (examples: SQL, HTML, Prolog)
 * implicit finalization forms

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

 * the standard  abstraction, to allow custom compile-time expansions of assignment/access operators
 * ,,   and other similar   macros
 * Depending on implementation,  or   is a macro built on the other, the special operator;   and   consist of macros
 * The powerful  domain-specific language

Macros are defined by the defmacro macro. The special operator macrolet allows the definition of local (lexically scoped) macros. It is also possible to define macros for symbols using define-symbol-macro and symbol-macrolet.

Paul Graham's book On Lisp describes the use of macros in Common Lisp in detail. 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." Hoyte provides several examples of iterative development of macros.

Example using a macro to define a new control structure
Macros allow Lisp programmers to create new syntactic forms in the language. One typical use is to create new control structures. The example macro provides an  looping construct. The syntax is:

The macro definition for until:

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. The backquote ` provides a notation that provides code templates, where the value of forms preceded with a comma are filled in. Forms preceded with comma and at-sign are spliced in. The tagbody form tests the end condition. If the condition is true, it jumps to the end tag. Otherwise, the provided body code is executed and then it jumps to the start tag.

An example of using the above until macro:

The code can be expanded using the function macroexpand-1. The expansion for the above example looks like this:

During macro expansion the value of the variable test is (= (random 10) 0) and the value of the variable body is ((write-line "Hello")). The body is a list of forms.

Symbols are usually automatically upcased. The expansion uses the TAGBODY with two labels. The symbols for these labels are computed by GENSYM and are not interned in any package. Two go forms use these tags to jump to. Since tagbody is a primitive operator in Common Lisp (and not a macro), it will not be expanded into something else. The expanded form uses the when macro, which also will be expanded. Fully expanding a source form is called code walking.

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

All macros must be expanded before the source code containing them can be evaluated or compiled normally. Macros can be considered functions that accept and return S-expressions – similar to abstract syntax trees, but not limited to those. These functions are invoked before the evaluator or compiler to produce the final source code. Macros are written in normal Common Lisp, and may use any Common Lisp (or third-party) operator available.

Variable capture and shadowing
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. 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.

Variable capture can introduce software defects. This happens in one of the following two ways:

 * 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.
 * 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.

The Scheme dialect of Lisp provides a macro-writing system which provides the referential transparency that eliminates both types of capture problem. 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).

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

One approach is to use gensyms: guaranteed-unique symbols which can be used in a macro-expansion without threat of capture. 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. 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. Gensyms could be used to provide stable aliases for the global symbols which the macro expansion needs. 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.

Another approach is to use packages. A macro defined in its own package can simply use internal symbols in that package in its expansion. The use of packages deals with type 1 and type 2 capture.

However, packages don't solve the type 1 capture of references to standard Common Lisp functions and operators. 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). Whereas the Common Lisp library symbols are external, and frequently imported into or made visible in user-defined packages.

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

The  macro will expand into a form which calls   which is intended to refer to the standard Common Lisp macro. However, in this context,  may have a completely different meaning, so   may not work properly.

Common Lisp solves the problem of the shadowing of standard operators and functions by forbidding their redefinition. Because it redefines the standard operator, the preceding is actually a fragment of non-conforming Common Lisp, which allows implementations to diagnose and reject it.

Condition system
The condition system is responsible for exception handling in Common Lisp. It provides conditions, handlers and restarts. Conditions are objects describing an exceptional situation (for example an error). If a condition is signaled, the Common Lisp system searches for a handler for this condition type and calls the handler. 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.

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. 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. The debugger itself can also be customized or replaced using the  dynamic variable. Code found within unwind-protect forms such as finalizers will also be executed as appropriate despite the exception.

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. The Lisp system presents four restarts. The user selects the Retry OPEN using a different pathname restart and enters a different pathname (lispm-init.lisp instead of lispm-int.lisp). The user code does not contain any error handling code. 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 Object System (CLOS)
Common Lisp includes a toolkit for object-oriented programming, the Common Lisp Object System or CLOS. 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.). 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. 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. As a dynamic object system, CLOS allows changes at runtime to generic functions and classes. 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.

CLOS has been integrated into ANSI Common Lisp. Generic functions can be used like normal functions and are a first-class data type. Every CLOS class is integrated into the Common Lisp type system. Many Common Lisp types have a corresponding class. There is more potential use of CLOS for Common Lisp. The specification does not say whether conditions are implemented with CLOS. Pathnames and streams could be implemented with CLOS. These further usage possibilities of CLOS for ANSI Common Lisp are not part of the standard. Actual Common Lisp implementations use CLOS for pathnames, streams, input–output, conditions, the implementation of CLOS itself and more.

Compiler and interpreter
A Lisp interpreter directly executes Lisp source code provided as Lisp objects (lists, symbols, numbers, ...) read from s-expressions. A Lisp compiler generates bytecode or machine code from Lisp source code. 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).

Several implementations of earlier Lisp dialects provided both an interpreter and a compiler. Unfortunately often the semantics were different. These earlier Lisps implemented lexical scoping in the compiler and dynamic scoping in the interpreter. Common Lisp requires that both the interpreter and compiler use lexical scoping by default. The Common Lisp standard describes both the semantics of the interpreter and a compiler. The compiler can be called using the function compile for individual functions and using the function compile-file for files. Common Lisp allows type declarations and provides ways to influence the compiler code generation policy. 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.

There is also a function to evaluate Lisp code:. takes code as pre-parsed s-expressions and not, like in some other languages, as text strings. 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. Several Common Lisp implementations (like Clozure CL and SBCL) are implementing  using their compiler. This way code is compiled, even though it is evaluated using the function.

The file compiler is invoked using the function compile-file. The generated file with compiled code is called a fasl (from fast load) file. These fasl files and also source code files can be loaded with the function load into a running Common Lisp system. 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 implementations can be used interactively, even though the code gets fully compiled. The idea of an Interpreted language thus does not apply for interactive Common Lisp.

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.

Some special operators are provided to especially suit interactive development; for instance,  will only assign a value to its provided variable if it wasn't already bound, while   will always perform the assignment. This distinction is useful when interactively evaluating, compiling and loading code in a live image.

Some features are also provided to help writing compilers and interpreters. Symbols consist of first-level objects and are directly manipulable by user code. The  special operator allows to create lexical bindings programmatically, while packages are also manipulable. The Lisp compiler is available at runtime to compile files or individual functions. These make it easy to use Lisp as an intermediate compiler or interpreter for another language.

Birthday paradox
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.). The answer is 23.

In Common Lisp, by convention, constants are enclosed with + characters.

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

Sorting a list of person objects
We define a class  and a method for displaying the name and age of a person. Next we define a group of persons as a list of  objects. Then we iterate over the sorted list.

It prints the three names with descending age.

Exponentiating by squaring
Use of the LOOP macro is demonstrated:

Example use:

Compare with the built in exponentiation:

Find the list of available shells
WITH-OPEN-FILE is a macro that opens a file and provides a stream. When the form is returning, the file is automatically closed. FUNCALL calls a function object. The LOOP collects all lines that match the predicate.

The function AVAILABLE-SHELLS calls the above function LIST-MATCHING-LINES with a pathname and an anonymous function as the predicate. The predicate returns the pathname of a shell or NIL (if the string is not the filename of a shell).

Example results (on Mac OS X 10.6):

Comparison with other Lisps
Common Lisp is most frequently compared with, and contrasted to, Scheme—if only because they are the two most popular Lisp dialects. Scheme predates CL, and comes not only from the same Lisp tradition but from some of the same engineers—Guy Steele, with whom Gerald Jay Sussman designed Scheme, chaired the standards committee for Common Lisp.

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). Unlike many earlier Lisps, Common Lisp (like Scheme) uses lexical variable scope by default for both interpreted and compiled code.

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. Scheme introduced the sole use of lexically scoped variables to Lisp; an inspiration from ALGOL 68. CL supports dynamically scoped variables as well, but they must be explicitly declared as "special". There are no differences in scoping between ANSI CL interpreters and compilers.

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. (In fact, CL has many namespaces, such as those for go tags, block names, and  keywords). There is a long-standing controversy between CL and Scheme advocates over the tradeoffs involved in multiple namespaces. In Scheme, it is (broadly) necessary to avoid giving variables names which clash with functions; Scheme functions frequently have arguments named,  , or   so as not to conflict with the system function. 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  example above.

CL also differs from Scheme in its handling of boolean values. Scheme uses the special values #t and #f to represent truth and falsity. CL follows the older Lisp convention of using the symbols T and NIL, with NIL standing also for the empty list. In CL, any non-NIL value is treated as true by conditionals, such as, whereas in Scheme all non-#f values are treated as true. 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.

Lastly, the Scheme standards documents require tail-call optimization, which the CL standard does not. Most CL implementations do offer tail-call optimization, although often only when the programmer uses an optimization directive. 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,  ,  , or (more recently) with the   package.

Implementations
See the Category Common Lisp implementations.

Common Lisp is defined by a specification (like Ada and C) rather than by one implementation (like Perl). There are many implementations, and the standard details areas in which they may validly differ.

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

 * Interactive Top-Level (REPL)
 * Garbage Collection
 * Debugger, Stepper and Inspector
 * Weak data structures (hash tables)
 * Extensible sequences
 * Extensible LOOP
 * Environment access
 * CLOS Meta-object Protocol
 * CLOS based extensible streams
 * CLOS based Condition System
 * Network streams
 * Persistent CLOS
 * Unicode support
 * Foreign-Language Interface (often to C)
 * Operating System interface
 * Java Interface
 * Threads and Multiprocessing
 * Application delivery (applications, dynamic libraries)
 * Saving of images

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 Common-Lisp.net and CLOCC (Common Lisp Open Code Collection) projects.

Common Lisp implementations may use any mix of native code compilation, byte code compilation or interpretation. Common Lisp has been designed to support incremental compilers, file compilers and block compilers. Standard declarations to optimize compilation (such as function inlining or type specialization) are proposed in the language specification. Most Common Lisp implementations compile source code to native machine code. Some implementations can create (optimized) stand-alone applications. Others compile to interpreted bytecode, which is less efficient than native code, but eases binary-code portability. Some compilers compile Common Lisp code to C code. 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. With Common Lisp incremental compilation is widely used.

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.

Commercial implementations

 * Allegro Common Lisp: for Microsoft Windows, FreeBSD, Linux, Apple macOS and various UNIX variants. Allegro CL provides an Integrated Development Environment (IDE) (for Windows and Linux) and extensive capabilities for application delivery.
 * Liquid Common Lisp: formerly called Lucid Common Lisp. Only maintenance, no new releases.
 * LispWorks: for Microsoft Windows, FreeBSD, Linux, Apple macOS, iOS, Android and various UNIX variants. LispWorks provides an Integrated Development Environment (IDE) (available for most platforms, but not for iOS and Android) and extensive capabilities for application delivery.
 * mocl: for iOS, Android and macOS.
 * Open Genera: for DEC Alpha.
 * Scieneer Common Lisp: which is designed for high-performance scientific computing.

Freely redistributable implementations

 * 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.
 * Clasp: A LLVM based implementation that seamlessly interoperates with C++ libraries. Runs on several Unix and Unix-like systems (including macOS).
 * 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.
 * 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.
 * 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.
 * Corman Common Lisp: for Microsoft Windows. In January 2015 Corman Lisp has been published under MIT license.
 * 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.
 * 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.
 * 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.
 * 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.
 * Movitz: Implements a Lisp environment for x86 computers without relying on any underlying OS.
 * 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.
 * 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 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.
 * Ufasoft Common Lisp: port of CLISP for windows platform with core written in C++.

Other implementations

 * Austin Kyoto Common Lisp: an evolution of Kyoto Common Lisp by Bill Schelter
 * Butterfly Common Lisp: an implementation written in Scheme for the BBN Butterfly multi-processor computer
 * CLICC: a Common Lisp to C compiler
 * CLOE: Common Lisp for PCs by Symbolics
 * Codemist Common Lisp: used for the commercial version of the computer algebra system Axiom
 * ExperCommon Lisp: an early implementation for the Apple Macintosh by ExperTelligence
 * Golden Common Lisp: an implementation for the PC by GoldHill Inc.
 * Ibuki Common Lisp: a commercialized version of Kyoto Common Lisp
 * Kyoto Common Lisp: the first Common Lisp compiler that used C as a target language. GCL, ECL and MKCL originate from this Common Lisp implementation.
 * L: a small version of Common Lisp for embedded systems developed by IS Robotics, now iRobot
 * Lisp Machines (from Symbolics, TI and Xerox ): provided implementations of Common Lisp in addition to their native Lisp dialect (Lisp Machine Lisp or Interlisp). CLOS was also available. Symbolics provides an enhanced version Common Lisp.
 * Procyon Common Lisp: an implementation for Windows and Mac OS, used by Franz for their Windows port of Allegro CL
 * Star Sapphire Common LISP: an implementation for the PC
 * SubL: a variant of Common Lisp used for the implementation of the Cyc knowledge-based system
 * Top Level Common Lisp: an early implementation for concurrent execution
 * WCL: a shared library implementation
 * VAX Common Lisp: Digital Equipment Corporation's implementation that ran on VAX systems running VMS or ULTRIX
 * XLISP: an implementation written by David Betz

Applications
Common Lisp is used to develop research applications (often in Artificial Intelligence), for rapid development of prototypes or for deployed applications.

Common Lisp is used in many commercial applications, including the Yahoo! Store web-commerce site, which originally involved Paul Graham and was later rewritten in C++ and Perl. Other notable examples include:

 * ACT-R, a cognitive architecture used in a large number of research projects.
 * Authorizer's Assistant, a large rule-based system used by American Express, analyzing credit requests.
 * Cyc, a long running project to create a knowledge-based system that provides a huge amount of common sense knowledge.
 * Gensym G2, a real-time expert system and business rules engine
 * Genworks GDL, based on the open-source Gendl kernel.
 * The development environment for the Jak and Daxter video game series, developed by Naughty Dog.
 * ITA Software's low fare search engine, used by travel websites such as Orbitz and Kayak.com and airlines such as American Airlines, Continental Airlines and US Airways.
 * Mirai, a 3D graphics suite. It was used to animate the face of Gollum in the movie Lord of the Rings: The Two Towers.
 * Opusmodus is a music composition system based on Common Lisp, used in Computer assisted composition.
 * Prototype Verification System (PVS), a mechanized environment for formal specification and verification.
 * PWGL is a sophisticated visual programming environment based on Common Lisp, used in Computer assisted composition and sound synthesis.
 * Piano, a complete aircraft analysis suite, written in Common Lisp, used by companies like Boeing, Airbus, and Northrop Grumman.
 * Grammarly, an English-language writing-enhancement platform, has its core grammar engine written in Common Lisp.
 * The Dynamic Analysis and Replanning Tool (DART), which is said to alone have paid back during the years from 1991 to 1995 for all thirty years of DARPA investments in AI research.
 * NASA's Jet Propulsion Lab's "Deep Space 1", an award-winning Common Lisp program for autopiloting the Deep Space One spaceship.
 * SigLab, a Common Lisp platform for signal processing used in missile defense, built by Raytheon.
 * NASA's Mars Pathfinder Mission Planning System.
 * SPIKE, a scheduling system for Earth or space based observatories and satellites, notably the Hubble Space Telescope, written in Common Lisp.
 * Common Lisp has been used for prototyping the garbage collector of Microsoft's .NET Common Language Runtime.
 * The original version of Reddit, though the developers later switched to Python due to the lack of libraries for Common Lisp, according to an official blog post by Reddit co-founder Steve Huffman.

There also exist open-source applications written in Common Lisp, such as:

 * ACL2, a full-featured automated theorem prover for an applicative variant of Common Lisp.
 * Axiom, a sophisticated computer algebra system.
 * Maxima, a sophisticated computer algebra system, based on Macsyma.
 * OpenMusic, an object-oriented visual programming environment based on Common Lisp, used in computer assisted composition.
 * Pgloader, a data loader for PostgreSQL, which was re-written from Python to Common Lisp.
 * Stumpwm, a tiling, keyboard driven X11 Window Manager written entirely in Common Lisp.

title: Common Lisp


text:
Color code

A color code is a system for encoding and representing non-color information with colors to facilitate communication. This information tends to be categorical (representing unordered/qualitative categories) though may also be sequential (representing an ordered/quantitative variable).

History
The earliest examples of color codes in use are for long-distance communication by use of flags, as in semaphore communication. The United Kingdom adopted a color code scheme for such communication wherein red signified danger and white signified safety, with other colors having similar assignments of meaning.

As chemistry and other technologies advanced, it became expedient to use coloration as a signal for telling apart things that would otherwise be confusingly similar, such as wiring in electrical and electronic devices, and pharmaceutical pills.

Encoded Variable
A color code encodes a variable, which may have different representations, where the color code type should match the variable type:
 * Categorical variable – the variable may represent discrete values of unordered qualitative data (e.g. blood type)
 * Binary variables are typically treated as a categorical variable (e.g. sex)
 * Quantitative variable – the variable represents ordered, quantitative data (e.g. age)
 * Discrete quantitative data (e.g. the 6 sides of a die: 1,2,3,4,5,6) are sometimes treated as a categorical variable, despite the ordered nature.

Types
The types of color code are:
 * Categorical – the colors are unordered, but are chosen to maximize saliency of the colors, by maximizing color difference between all color pair permutations.
 * Continuous – the colors are ordered and form a smooth color gradient.
 * Discrete – only a subset of a continuous color code are used (still ordered), where each is distinguishable from the others.

Categorical
When color is the only varied attribute, the color code is unidimensional. When other attributes are varied (e.g. shape, size), the code is multidimensional, where the dimensions can be independent (each encoding separate variables) or redundant (encoding the same variable). Partial redundancy sees one variable as a subset of another. For example, playing card suits are multidimensional with color (black, red) and shape (club, diamond, heart, spade), which are partially redundant since clubs and spades are always black and diamonds and hearts are always red. Tasks using categorical color codes can be classified as identification tasks, where a single stimulus is shown and must be identified (connotatively or denotatively), versus search tasks, where a color stimulus must be found within a field of heterogenous stimuli. Performance in these tasks is measured by speed and/or accuracy.

The ideal color scheme for a categorical color code depends on whether speed or accuracy is more important. Despite humans being able to distinguish 150 distinct colors along the hue dimension during comparative task, evidence supports that color schemes where colors differ only by hue (equal luminosity and colorfulness) should have a maximum of 8eightcategories with optimized stimulus spacing along the hue dimension, though this would not be color blind accessible. The IALA recommends categorical color codes in seven colors: red, orange, yellow, green, blue, white and black. Adding redundant coding of luminosity and colorfulness adds information and increases speed and accuracy of color decoding tasks. Color codes are superior to others (encoding to letters, shape, size, etc.) in certain types of tasks. Adding color as a redundant attribute to a numeral or letter encoding in search tasks decreased time by 50–75%, but in unidimensional identification tasks, using alphanumeric or line inclination codes caused less errors than color codes.

Several studies demonstrate a subjective preference for color codes over achromatic codes (e.g. shapes), even in studies where color coding did not increase performance over achromatic coding. Subjects reported the tasks as less monotonous and less inducing of eye strain and fatigue.

The ability to discriminate color differences decreases rapidly as the visual angle subtends less than 12' (0.2° or ~2 mm at a viewing distance of 50 cm), so color stimulus of at least 3 mm in diameter or thickness is recommended when the color is on paper or on a screen. Under normal conditions, colored backgrounds do not affect the interpretation of color codes, but chromatic (and/or low) illumination of surface color code can degrade performance.

Criticism
Color codes present some potential problems. On forms and signage, the use of color can distract from black and white text.

Color codes are often designed without consideration for accessibility to color blind and blind people, and may even be inaccessible for those with normal color vision, since use of many colors to code many variables can lead to use of confusingly similar colors. Only 15–40% of the colorblind can correctly name surface color codes with 8–10 color categories, most of which test as mildly colorblind. This finding uses ideal illumination; when dimmer illumination is used, performance drops sharply.

Examples
Systems incorporating color-coding include:

 * In electricity:
 * 25-pair color code – telecommunications wiring
 * Audio connectors
 * Video connectors
 * Optical fibers
 * Electrical wiring – AC power phase, neutral, and grounding wires
 * Electronic color code AKA resistor or EIA color code (today – IEC 60062:2016)
 * Ethernet twisted-pair wiring – local area networks
 * Jumper cables used to jump-start a vehicle
 * PC99 connectors and ports
 * Surround sound ports and cables
 * Three-phase electric power (electrical wiring)
 * In video games
 * Health and magic points
 * To distinguish friend from foe, for instance in StarCraft, Halo, or League of Legends
 * To distinguish rarity or quality of items in adventure and role-playing games
 * In navigation:
 * Characteristic light
 * Navigation light
 * Sea mark
 * Traffic lights
 * Other technology:
 * At point of sale (especially for packaging within a huge range of products: to quickly differentiate variants, brands, categories)
 * Bottled gases
 * Fire extinguishers
 * Kerbside collection
 * Pipe marking
 * Queen bee birth year code
 * Underground utility location
 * Hospital emergency codes often incorporate colors (such as the widely used "Code Blue" indicating a cardiac arrest),
 * In military use:
 * Homeland Security Advisory System
 * Artillery shells and other munitions, which are color-coded according to their pyrotechnic contents
 * List of Rainbow Codes
 * NATO Military Symbols for Land Based Systems
 * Rainbow Herbicides
 * In social functions:
 * Black hat hacking, white hat, grey hat
 * Blue-collar worker, white-collar worker, pink-collar worker, grey-collar, green-collar worker
 * Handkerchief code
 * ISO 22324, Guidelines for color-coded alerts in public warning
 * Cooper's Color Code of the combat mindset
 * Rank in Judo
 * Ribbon colors see: Category:Ribbon symbolism
 * In religion:
 * Clerical vestments, frontals and altar hangings in Christian churches

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: Color code


text:
Talk:Color

Reference the article primary colors at it's first appearance in the article
Change: Similarly, most human color perceptions can be generated by a mixture of three colors called primaries. This is used to reproduce color scenes in photography, printing, television, and other media. There are a number of methods or color spaces for specifying a color in terms of three particular primary colors. Each method has its advantages and disadvantages depending on the particular application.

to: Similarly, most human color perceptions can be generated by a mixture of three colors called primaries. This is used to reproduce color scenes in photography, printing, television, and other media. There are a number of methods or color spaces for specifying a color in terms of three particular primary colors. Each method has its advantages and disadvantages depending on the particular application.

Maybe a variation of the Munsell system would be a more elegant way to create each "shades of x" article
I started out thinking that the RGB system was the way to go, but I soon noticed its shortcomings. One of them is that its colour wheel is not balanced. For example, the transition from red to yellow is way too short in the wheel. After seeing many different colour wheels, I believe that Munsell's is the most balanced when it comes to doing justice to each hue's space in the colour wheel, and not overemphasising others. It makes the most sense while looking at the spectral colours in firsthand through a prism. It also has the property that each one of these hues is really close to its complementary. Please let me know what you think.

Example of how it would look like (for the hues only, it excludes brown or pink, for example):

1 Shades of red

2 Shades of orange

3 Shades of yellow

4 Shades of chartreuse/lime (main representative colour being near #98cf00)

5 Shades of green (main representative colour being near #19d451)

6 Shades of cyan/aqua (near #00c7b0)

7 Shades of blue (near #1f9bed)

8 Shades of ultramarine/indigo (near #6369ff)

9 Shades of purple/violet (near #bf66ff)

0 Shades of magenta (near #ff57b3)

You can also notice that these colours match their complementaries really well:

red-cyan

orange-blue

yellow-ultramarine (it's the same hue as the RGB 0000FF)

chartreuse-purple/violet

Amecordo

the   dogg     side      effects: 1%$32466587+90?).  (8)       — Preceding unsigned comment added by 103.189.176.3 (talk) 05:57, 29 February 2024 (UTC)

green-magenta

The RGB red is slightly orange-ish. If you look at the red through a prism, you can clearly see that there is a redder red than the RGB one. If we try to find the complementary for this pure red, it falls somewhere between 170 to 180 degrees in the HSV hue wheel.

I also think that the archetypical blue should be something around 210 degrees, because that's what most people and cultures think of the archetypical blue. The RGB blue is slightly violet-ish.

So my proposal is to: 1 merge 'shades of cyan' and 'shades of spring green' and call it 'shades of blue-green'.

2 rename 'shades of azure' as 'shades of blue' and add some new colours to it that represent both the blues closer to cyan and the blues closer to ultramarine.

3 rename 'shades of blue' as 'shades of ultramarine or indigo', and move some of the colours there to the new 'shades of blue'.

4 merge 'shades of magenta' with 'shades of rose'.

Let me know what you think. Restfultree2022 (talk) 08:41, 14 April 2023 (UTC)

 * Take a look at ISCC–NBS system. –jacobolus (t) 09:35, 14 April 2023 (UTC)
 * In my opinion, I think it's missing blue-green, magenta (those hues between 300 and 350 degrees), and ultramarine (between 230 and 255 degrees) as primary hues. In my opinion, these hue areas deserve acknowledgement on par with 'shades of red' and so on. Restfultree2022 (talk) 22:01, 14 April 2023 (UTC)
 * These are all given clear and unambiguous names. "Magenta" is called purplish red (pR), "ultramarine" is called purplish blue (pB). Also "teal"/"turquoise" is split into bluish green (bG) and greenish blue (gB) (though personally I might instead make a single blue–green category a bit smaller than the combination of those two put together). The point was to make precisely defined categories, not to give every category a one-word name. Anyway, this is more or less what you were asking or: a clearly specified system based on Munsell coordinates. –jacobolus (t) 23:06, 14 April 2023 (UTC)
 * I see. Yeah, what I'm mostly pondering on is what the exemplary colour code should be for the archetype of each hue.
 * It's also about the balance of the colour wheel. I see more difference between red to yellow than red to RGB magenta for example. The RGB green is slightly yellower than the greenest green I can see in the spectrum. The RGB colour wheel gets quite strange around green. One it gets near 120 degrees, there is very minimum difference. That's not what happens in the rainbow. I think it has something to do with how limited the sRGB gamut is about making those greens. Restfultree2022 (talk) 01:58, 15 April 2023 (UTC)
 * I'm thinking, maybe this is the most balanced way to divide the colour wheel: https://imgur.com/a/hOYTYFJ
 * But I'm not sure. Restfultree2022 (talk) 02:34, 15 April 2023 (UTC)

Ungrammatical
The second sentence in the section "Colors of objects" is this:

"Most objects scatters light to some degree and do not reflect or transmit light specularly like glasses or mirrors."
 * Corrected. Constant314 (talk) 07:13, 24 July 2023 (UTC)

Semi-protected edit request on 23 January 2024
I would like to add more information. 76.80.235.226 (talk) 21:32, 23 January 2024 (UTC)

Not done: this is not the right page to request additional user rights. You may reopen this request with the specific changes to be made and someone may add them for you, or if you have an account, you can wait until you are autoconfirmed and edit the page yourself. PianoDan (talk) 21:45, 23 January 2024 (UTC)

Semi-protected edit request on 20 March 2024
This page is protected but doesn't display any corresponding icon or banner, which I found a bit confusing..., I think?

- 2A02:560:5829:B000:B9F7:CF82:EEE5:7596 (talk) 13:26, 20 March 2024 (UTC)

 * Done.-- ♦Ian Ma c M♦  (talk to me) 13:46, 20 March 2024 (UTC)

title: Talk:Color


text:
CGI

CGI may refer to:

Technology

 * Computer-generated imagery, computer-graphic effects in films, television programs, and other visual media
 * Computer Graphics Interface, the low-level interface between the Graphical Kernel System and hardware
 * Common Gateway Interface, a standard for dynamic generation of web pages by a web server
 * CGI.pm, a Perl module for implementing Common Gateway Interface programs
 * Compacted graphite iron, a type of cast iron
 * Corrugated galvanised iron, a type of molded sheet metal
 * Cell Global Identity, a standard identifier for mobile phone cells

Organizations

 * California Graduate Institute, an independent graduate school specializing in psychology
 * Catholic Guides of Ireland, a Girl Guide association
 * Chulabhorn Graduate Institute, a private graduate institute in Thailand
 * CGI Aero or RusAir, a Russian airline
 * CGI Inc., a multinational information technology and business process services company
 * Clinton Global Initiative, a forum created by former US President Bill Clinton to discuss global problems
 * Coast Guard Intelligence, the intelligence branch of the United States Coast Guard
 * Commission for the Management and Application of Geoscience Information
 * Compagnie Générale Immobiliere, a Moroccan real-estate development company
 * Consultative Group on Indonesia, a former consortium of donors to the Indonesian government
 * Cuerpo Guardia de Infantería, an Argentine police riot control service
 * General Commissariat of Information, the Comisaría General de Información is an intelligence service within the National Police Corps of Spain.

Other uses

 * Clinical global impression, a family of scales to assess treatment response associated with mental disorders
 * Cognitively Guided Instruction, an approach to mathematics teaching and learning
 * CpG islands, in genetics, genomic regions that contain a high frequency of CG dinucleotides
 * Cape Girardeau Regional Airport (IATA airport code: CGI), an airport in Missouri, US

title: CGI


text:
Cortex

Cortex or cortical may refer to:

Biology

 * Cortex (anatomy), the outermost layer of an organ
 * Cerebral cortex, the outer layer of the vertebrate cerebrum, part of which is the forebrain
 * Motor cortex, the regions of the cerebral cortex involved in voluntary motor functions
 * Prefrontal cortex, the anterior part of the frontal lobes of the brain
 * Visual cortex, regions of the cerebral cortex involved in visual functions
 * Cerebellar cortex, the outer layer of the vertebrate cerebellum
 * Renal cortex, the outer portion of the kidney
 * Adrenal cortex, a portion of the adrenal gland
 * Cell cortex, the region of a cell directly underneath the membrane
 * Cortex (hair), the middle layer of a strand of hair
 * Cortex (botany), the outer portion of the stem or root of a plant

Entertainment

 * Cortex (film), a 2008 French film directed by Nicolas Boukhrief

 * Cortex (podcast), a 2015 podcast
 * Doctor Neo Cortex, a fictional character in the Crash Bandicoot video game series
 * Nina Cortex, the niece of Neo Cortex
 * Cortex (band), a French jazz funk band featuring Alain Mion
 * Cortex, a Swedish post-punk alternative band featuring Freddie Wadling

Other uses

 * Cortex (archaeology), the outer layer of rock formed on the exterior of raw materials by chemical and mechanical weathering processes
 * Cortex (journal), cognitive science journal published by Elsevier
 * Cortex, a family of the ARM architecture of CPUs
 * Cortex, a division of Gemini Sound Products
 * Cortex, a digital lending platform by Think Finance
 * Cortex Pharmaceuticals, a company of New Jersey, United States
 * Cortex Innovation Community, a district in St. Louis, Missouri, United States

title: Cortex


text:
Collection

Collection or Collections may refer to:
 * Cash collection, the function of an accounts receivable department
 * Collection (church), money donated by the congregation during a church service
 * Collection agency, agency to collect cash
 * Collections management (museum)
 * Collection (museum), objects in a particular field forms the core basis for the museum
 * Fonds in archives
 * Private collection, sometimes just called "collection"
 * Collection (Oxford colleges), a beginning-of-term exam or Principal's Collections
 * Collection (horse), a horse carrying more weight on his hindquarters than his forehand
 * Collection (racehorse), an Irish-bred, Hong Kong based Thoroughbred racehorse
 * Collection (publishing), a gathering of books under the same title at the same publisher
 * Scientific collection, any systematic collection of objects for scientific study

Collection may also refer to:

Computing

 * Collection (abstract data type), the abstract concept of collections in computer science
 * Collection (linking), the act of linkage editing in computing
 * Garbage collection (computing), automatic memory management method

Mathematics

 * Set (mathematics)
 * Class (set theory)
 * Family of sets
 * Indexed family
 * Multiset
 * Parametric family

Collection

 * Collection (2NE1 album), 2012
 * Collection (Agnes album), 2013
 * Collection (Arvingarna album), 2002
 * Collection (Jason Becker album), 2008
 * Collection (Tracy Chapman album), 2001
 * Collection (The Charlatans album)
 * Collection (Dave Grusin album), 1989
 * Collection (The Jam album)
 * Collection (Wynonna Judd album)
 * Collection (Magnus Uggla album), 1985
 * Collection (Men Without Hats album), 1996
 * Collection (MFÖ album), 2003
 * Collection (Mike Oldfield album), 2002
 * Collection (Praxis album), 1998
 * Collection (The Rankin Family album), 1996
 * Collection (Lee Ritenour album), 1991
 * Collection (Joe Sample album), 1991
 * Collection (Spyro Gyra album), 1991
 * Collection (The Stranglers album), 1998
 * Collection (Suicidal Tendencies album), 1993
 * Collection (Thee Michelle Gun Elephant album), 2001
 * Collection (The Warratahs album), 2003
 * Collection: The Shrapnel Years (Greg Howe album), 2006
 * Collection: The Shrapnel Years (Tony MacAlpine album), 2006
 * Collection: The Shrapnel Years (Vinnie Moore album), 2006
 * Collection I, a 1986 compilation album of songs by the Misfits
 * Collection II, a 1995 companion album to the Misfits' Collection I

Collections

 * Collections (Alexia album)
 * Collections (Rick Astley album), 2006
 * Collections (Cypress Hill album)
 * Collections (Terence Trent D'Arby album), 2006
 * Collections (Delphic album), 2013
 * Collections (Amanda Marshall album), 2006
 * Collections (Charlie Major album), 2006
 * Collections (Red Norvo, Art Pepper, Joe Morello and Gerry Wiggins album), 1957
 * Collections (Yanni album), 2008
 * Collections (The Young Rascals album), 1967

Other uses

 * Collection (film), a 2021 film starring Alex Petttyfer
 * Collection #1, a database of sets of email addresses and passwords
 * Collections care, to prevent or delay the deterioration of cultural heritage
 * Collection class, in object-oriented programming
 * Generated collection, a musical scale formed by repeatedly adding a constant interval around the chromatic circle

title: Collection


text:
Cauchy sequence

In mathematics, a Cauchy sequence is a sequence whose elements become arbitrarily close to each other as the sequence progresses. More precisely, given any small positive distance, all excluding a finite number of elements of the sequence are less than that given distance from each other. Cauchy sequences are named after Augustin-Louis Cauchy; they may occasionally be known as fundamental sequences.

It is not sufficient for each term to become arbitrarily close to the term. For instance, in the sequence of square roots of natural numbers: $$a_n=\sqrt n,$$ the consecutive terms become arbitrarily close to each other – their differences $$a_{n+1}-a_n = \sqrt{n+1}-\sqrt{n} = \frac{1}{\sqrt{n+1}+\sqrt{n}} < \frac{1}{2\sqrt n}$$ tend to zero as the index $n$ grows. However, with growing values of $n$, the terms $$a_n$$ become arbitrarily large. So, for any index $n$ and distance $d$, there exists an index $m$ big enough such that $$a_m - a_n > d.$$ As a result, no matter how far one goes, the remaining terms of the sequence never get close to ; hence the sequence is not Cauchy.

The utility of Cauchy sequences lies in the fact that in a complete metric space (one where all such sequences are known to converge to a limit), the criterion for convergence depends only on the terms of the sequence itself, as opposed to the definition of convergence, which uses the limit value as well as the terms. This is often exploited in algorithms, both theoretical and applied, where an iterative process can be shown relatively easily to produce a Cauchy sequence, consisting of the iterates, thus fulfilling a logical condition, such as termination.

Generalizations of Cauchy sequences in more abstract uniform spaces exist in the form of Cauchy filters and Cauchy nets.

In real numbers
A sequence $$x_1, x_2, x_3, \ldots$$ of real numbers is called a Cauchy sequence if for every positive real number $$\varepsilon,$$ there is a positive integer N such that for all natural numbers $$m, n > N,$$ $$|x_m - x_n| < \varepsilon,$$ where the vertical bars denote the absolute value. In a similar way one can define Cauchy sequences of rational or complex numbers. Cauchy formulated such a condition by requiring $$x_m - x_n$$ to be infinitesimal for every pair of infinite m, n.

For any real number r, the sequence of truncated decimal expansions of r forms a Cauchy sequence. For example, when $$r = \pi,$$ this sequence is (3, 3.1, 3.14, 3.141, ...). The mth and nth terms differ by at most $$10^{1-m}$$ when m < n, and as m grows this becomes smaller than any fixed positive number $$\varepsilon.$$

Modulus of Cauchy convergence
If $$(x_1, x_2, x_3, ...)$$ is a sequence in the set $$X,$$ then a modulus of Cauchy convergence for the sequence is a function $$\alpha$$ from the set of natural numbers to itself, such that for all natural numbers $$k$$ and natural numbers $$m, n > \alpha(k),$$ $$|x_m - x_n| < 1/k.$$

Any sequence with a modulus of Cauchy convergence is a Cauchy sequence. The existence of a modulus for a Cauchy sequence follows from the well-ordering property of the natural numbers (let $$\alpha(k)$$ be the smallest possible $$N$$ in the definition of Cauchy sequence, taking $$\varepsilon$$ to be $$1/k$$). The existence of a modulus also follows from the principle of countable choice. Regular Cauchy sequences are sequences with a given modulus of Cauchy convergence (usually $$\alpha(k) = k$$ or $$\alpha(k) = 2^k$$). Any Cauchy sequence with a modulus of Cauchy convergence is equivalent to a regular Cauchy sequence; this can be proven without using any form of the axiom of choice.

Moduli of Cauchy convergence are used by constructive mathematicians who do not wish to use any form of choice. Using a modulus of Cauchy convergence can simplify both definitions and theorems in constructive analysis. Regular Cauchy sequences were used by and by  in constructive mathematics textbooks.

In a metric space
Since the definition of a Cauchy sequence only involves metric concepts, it is straightforward to generalize it to any metric space X. To do so, the absolute value $$\left|x_m - x_n\right|$$ is replaced by the distance $$d\left(x_m, x_n\right)$$ (where d denotes a metric) between $$x_m$$ and $$x_n.$$

Formally, given a metric space $$(X, d),$$ a sequence $$x_1, x_2, x_3, \ldots$$ is Cauchy, if for every positive real number $$\varepsilon > 0$$ there is a positive integer $$N$$ such that for all positive integers $$m, n > N,$$ the distance $$d\left(x_m, x_n\right) < \varepsilon.$$

Roughly speaking, the terms of the sequence are getting closer and closer together in a way that suggests that the sequence ought to have a limit in X. Nonetheless, such a limit does not always exist within X: the property of a space that every Cauchy sequence converges in the space is called completeness, and is detailed below.

Completeness
A metric space (X, d) in which every Cauchy sequence converges to an element of X is called complete.

Examples
The real numbers are complete under the metric induced by the usual absolute value, and one of the standard constructions of the real numbers involves Cauchy sequences of rational numbers. In this construction, each equivalence class of Cauchy sequences of rational numbers with a certain tail behavior—that is, each class of sequences that get arbitrarily close to one another— is a real number.

A rather different type of example is afforded by a metric space X which has the discrete metric (where any two distinct points are at distance 1 from each other). Any Cauchy sequence of elements of X must be constant beyond some fixed point, and converges to the eventually repeating term.

Non-example: rational numbers
The rational numbers $$\Q$$ are not complete (for the usual distance): There are sequences of rationals that converge (in $$\R$$) to irrational numbers; these are Cauchy sequences having no limit in $$\Q.$$ In fact, if a real number x is irrational, then the sequence (xn), whose n-th term is the truncation to n decimal places of the decimal expansion of x, gives a Cauchy sequence of rational numbers with irrational limit x. Irrational numbers certainly exist in $$\R,$$ for example:

 * The sequence defined by $$x_0=1, x_{n+1}=\frac{x_n+2/x_n}{2}$$ consists of rational numbers (1, 3/2, 17/12,...), which is clear from the definition; however it converges to the irrational square root of 2, see Babylonian method of computing square root.
 * The sequence $$x_n = F_n / F_{n-1}$$ of ratios of consecutive Fibonacci numbers which, if it converges at all, converges to a limit $$\phi$$ satisfying $$\phi^2 = \phi+1,$$ and no rational number has this property. If one considers this as a sequence of real numbers, however, it converges to the real number $$\varphi = (1+\sqrt5)/2,$$ the Golden ratio, which is irrational.
 * The values of the exponential, sine and cosine functions, exp(x), sin(x), cos(x), are known to be irrational for any rational value of $$x \neq 0,$$ but each can be defined as the limit of a rational Cauchy sequence, using, for instance, the Maclaurin series.

Non-example: open interval
The open interval $$X = (0, 2)$$ in the set of real numbers with an ordinary distance in $$\R$$ is not a complete space: there is a sequence $$x_n = 1/n$$ in it, which is Cauchy (for arbitrarily small distance bound $$d > 0$$ all terms $$x_n$$ of $$n > 1/d$$ fit in the $$(0, d)$$ interval), however does not converge in $$X$$ — its 'limit', number 0, does not belong to the space $$X .$$

Other properties

 * Every convergent sequence (with limit s, say) is a Cauchy sequence, since, given any real number $$\varepsilon > 0,$$ beyond some fixed point, every term of the sequence is within distance $$\varepsilon/2$$ of s, so any two terms of the sequence are within distance $$\varepsilon$$ of each other.
 * In any metric space, a Cauchy sequence $$x_n$$ is bounded (since for some N, all terms of the sequence from the N-th onwards are within distance 1 of each other, and if M is the largest distance between $$x_N$$ and any terms up to the N-th, then no term of the sequence has distance greater than $$M + 1$$ from $$x_N$$).
 * In any metric space, a Cauchy sequence which has a convergent subsequence with limit s is itself convergent (with the same limit), since, given any real number r > 0, beyond some fixed point in the original sequence, every term of the subsequence is within distance r/2 of s, and any two terms of the original sequence are within distance r/2 of each other, so every term of the original sequence is within distance r of s.

These last two properties, together with the Bolzano–Weierstrass theorem, yield one standard proof of the completeness of the real numbers, closely related to both the Bolzano–Weierstrass theorem and the Heine–Borel theorem. Every Cauchy sequence of real numbers is bounded, hence by Bolzano–Weierstrass has a convergent subsequence, hence is itself convergent. This proof of the completeness of the real numbers implicitly makes use of the least upper bound axiom. The alternative approach, mentioned above, of the real numbers as the completion of the rational numbers, makes the completeness of the real numbers tautological.

One of the standard illustrations of the advantage of being able to work with Cauchy sequences and make use of completeness is provided by consideration of the summation of an infinite series of real numbers (or, more generally, of elements of any complete normed linear space, or Banach space). Such a series $\sum_{n=1}^{\infty} x_n$ is considered to be convergent if and only if the sequence of partial sums $$(s_{m})$$ is convergent, where  $s_m = \sum_{n=1}^{m} x_n.$  It is a routine matter to determine whether the sequence of partial sums is Cauchy or not, since for positive integers $$p > q,$$ $$s_p - s_q = \sum_{n=q+1}^p x_n.$$

If $$f : M \to N$$ is a uniformly continuous map between the metric spaces M and N and (xn) is a Cauchy sequence in M, then $$(f(x_n))$$ is a Cauchy sequence in N. If $$(x_n)$$ and $$(y_n)$$ are two Cauchy sequences in the rational, real or complex numbers, then the sum $$(x_n + y_n)$$ and the product $$(x_n y_n)$$ are also Cauchy sequences.

In topological vector spaces
There is also a concept of Cauchy sequence for a topological vector space $$X$$: Pick a local base $$B$$ for $$X$$ about 0; then ($$x_k$$) is a Cauchy sequence if for each member $$V\in B,$$ there is some number $$N$$ such that whenever $$n,m > N, x_n - x_m$$ is an element of $$V.$$ If the topology of $$X$$ is compatible with a translation-invariant metric $$d,$$ the two definitions agree.

In topological groups
Since the topological vector space definition of Cauchy sequence requires only that there be a continuous "subtraction" operation, it can just as well be stated in the context of a topological group: A sequence $$(x_k)$$ in a topological group $$G$$ is a Cauchy sequence if for every open neighbourhood $$U$$ of the identity in $$G$$ there exists some number $$N$$ such that whenever $$m,n>N$$ it follows that $$x_n x_m^{-1} \in U.$$ As above, it is sufficient to check this for the neighbourhoods in any local base of the identity in $$G.$$

As in the construction of the completion of a metric space, one can furthermore define the binary relation on Cauchy sequences in $$G$$ that $$(x_k)$$ and $$(y_k)$$ are equivalent if for every open neighbourhood $$U$$ of the identity in $$G$$ there exists some number $$N$$ such that whenever $$m,n>N$$ it follows that $$x_n y_m^{-1} \in U.$$ This relation is an equivalence relation: It is reflexive since the sequences are Cauchy sequences. It is symmetric since $$y_n x_m^{-1} = (x_m y_n^{-1})^{-1} \in U^{-1}$$ which by continuity of the inverse is another open neighbourhood of the identity. It is transitive since $$x_n z_l^{-1} = x_n y_m^{-1} y_m z_l^{-1} \in U' U$$ where $$U'$$ and $$U$$ are open neighbourhoods of the identity such that $$U'U'' \subseteq U$$; such pairs exist by the continuity of the group operation.

In groups
There is also a concept of Cauchy sequence in a group $$G$$: Let $$H=(H_r)$$ be a decreasing sequence of normal subgroups of $$G$$ of finite index. Then a sequence $$(x_n)$$ in $$G$$ is said to be Cauchy (with respect to $$H$$) if and only if for any $$r$$ there is $$N$$ such that for all $$m, n > N, x_n x_m^{-1} \in H_r.$$

Technically, this is the same thing as a topological group Cauchy sequence for a particular choice of topology on $$G,$$ namely that for which $$H$$ is a local base.

The set $$C$$ of such Cauchy sequences forms a group (for the componentwise product), and the set $$C_0$$ of null sequences (sequences such that $$\forall r, \exists N, \forall n > N, x_n \in H_r$$) is a normal subgroup of $$C.$$ The factor group $$C/C_0$$ is called the completion of $$G$$ with respect to $$H.$$

One can then show that this completion is isomorphic to the inverse limit of the sequence $$(G/H_r).$$

An example of this construction familiar in number theory and algebraic geometry is the construction of the $p$-adic completion of the integers with respect to a prime $$p.$$ In this case, $$G$$ is the integers under addition, and $$H_r$$ is the additive subgroup consisting of integer multiples of $$p_r.$$

If $$H$$ is a cofinal sequence (that is, any normal subgroup of finite index contains some $$H_r$$), then this completion is canonical in the sense that it is isomorphic to the inverse limit of $$(G/H)_H,$$ where $$H$$ varies over normal subgroups of finite index. For further details, see Ch. I.10 in Lang's "Algebra".

In a hyperreal continuum
A real sequence $$\langle u_n : n \in \N \rangle$$ has a natural hyperreal extension, defined for hypernatural values H of the index n in addition to the usual natural n. The sequence is Cauchy if and only if for every infinite H and K, the values $$u_H$$ and $$u_K$$ are infinitely close, or adequal, that is,
 * $$\mathrm{st}(u_H-u_K)= 0$$

where "st" is the standard part function.

Cauchy completion of categories
introduced a notion of Cauchy completion of a category. Applied to $$\Q$$ (the category whose objects are rational numbers, and there is a morphism from x to y if and only if $$x \leq y$$), this Cauchy completion yields $$\R\cup\left\{\infty\right\}$$ (again interpreted as a category using its natural ordering).

title: Cauchy sequence