A character is an object that represents a unitary token (e.g., a letter, a special symbol, or a “control character”) in an aggregate quantity of text (e.g., a string or a text stream).
Common Lisp allows an implementation to provide support for international language characters as well as characters used in specialized arenas (e.g., mathematics).
The following figures contain lists of defined names applicable to characters.
The next figure lists some defined names relating to character attributes and character predicates.
Figure 13–1. Character defined names – 1
The next figure lists some character construction and conversion defined names.
char-code | char-name | code-char |
char-downcase | char-upcase | digit-char |
char-int | character | name-char |
Figure 13–2. Character defined names – 2
A script is one of possibly several sets that form an exhaustive partition of the type character.
The number of such sets and boundaries between them is implementation-defined. Common Lisp does not require these sets to be types, but an implementation is permitted to define such types as an extension. Since no character from one script can ever be a member of another script, it is generally more useful to speak about character repertoires.
For some examples of \term{repertoires}, see the coded character standards ISO 8859/1, ISO 8859/2, and ISO 6937/2. Note, however, that althoughAlthough the term “script” is chosen for namingdefinitional compatibility with ISO terminology, no conforming implementation is required to use any particular scripts standardized by ISO or by any other standards organization.
Whether and how the script or scripts used by any given implementation are named is implementation-dependent.
A repertoire is a type specifier for a subtype of type character. This term is generally used when describing a collection of characters independent of their coding. Characters in repertoires are only identified by name, by glyph, or by character description.
A repertoire can contain characters from several scripts, and a character can appear in more than one repertoire.
For some examples of repertoires, see the coded character standards ISO 8859/1, ISO 8859/2, and ISO 6937/2. Note, however, that although Althoughthe term “repertoire” is chosen for namingdefinitional compatibility with ISO terminology, no conforming implementation is required to use repertoires standardized by ISO or any other standards organization.
13.1.0 1 Characters have only one standardized attribute: a code. A character's code is a non-negative integer. This code is composed from a character script and a character label in an implementation-dependent way. See the functions char-code and code-char.
13.5.0 1 Remarks about the bits and font \term{attributes} removed. -kmp
Additional, implementation-defined attributes of characters are also permitted so that, for example, two characters with the same code may differ in some other, implementation-defined way.
For any implementation-defined attribute there is a distinguished value called the null value for that attribute. A character for which each implementation-defined attribute has the null value for that attribute is called a simple character. If the implementation has no implementation-defined attributes, then all characters are simple characters.
For each implementation-defined attribute of a character, the documentation for that implementation must specify whether characters that differ only in that attribute are permitted to differ in whether or not they are members of one of the aforementioned categories.
Note that these terms are defined independently of any special syntax which might have been enabled in the current readtable.
Characters that are classified as graphic, or displayable, are each associated with a glyph, a visual representation of the character.
13.2.0 7
A graphic character is one that has a standard textual representation as a single glyph, such as A or * or =. Space, which effectively has a blank glyph, is defined to be a graphic.
Of the standard characters, newline is non-graphic and all others are graphic; see Section 2.1.3 (Standard Characters).
Characters that are not graphic are called non-graphic. Non-graphic characters are sometimes informally called “formatting characters” or “control characters.”
#\Backspace, #\Tab, #\Rubout, #\Linefeed, #\Return, and #\Page, if they are supported by the implementation, are non-graphic.
!!! I'm not completely sure it was proper for whoever removed this to have done so. -kmp 16-Oct-91 13.2.0 6 \term{Graphic characters} of font 0 are all of the same width when printed. Every implementation of \clisp\ must provide some mode of operation in which font 0 is a fixed-pitch font.
13.2.0 7 Any character with a non-zero bits \term{attribute} is \term{non-graphic}.
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
13.2.0 16Any implementation-defined character that has case must be alphabetic1. For each implementation-defined graphic character that has no case, it is implementation-defined whether that character is alphabetic1.
The characters with case are a subset of the alphabetic1 characters. A character with case has the property of being either uppercase or lowercase. Every character with case is in one-to-one correspondence with some other character with the opposite case.
13.2.0 17
char-downcase).
Of the standard characters, only these are uppercase characters:
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
char-upcase).
Of the standard characters, only these are lowercase characters:
a b c d e f g h i j k l m n o p q r s t u v w x y z
A through Z mentioned above respectively correspond to the lowercase standard characters a through z mentioned above. For example, the uppercase character E corresponds to the lowercase character e, and vice versa.
0 1 2 3 4 5 6 7 8 9
For each implementation-defined graphic character that has no case, the implementation must define whether or not it is a numeric character.
What qualifies as a digit depends on the radix (an integer between 2 and 36, inclusive). The potential digits are:
0 1 2 3 4 5 6 7 8 9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Their respective weights are 0, 1, 2, 35. In any given radix , only the first potential digits are considered to be digits. For example, the digits in radix 2 are 0 and 1, the digits in radix 10 are 0 through 9, and the digits in radix 16 are 0 through F.
Case is not significant in digits; for example, in radix 16, both F and f are digits with weight 15.
!!! KMP: I couldn't figure out whether there can be implementation-defined digits. It doesn't seem like a good idea because the obvious choices are things like ``\~n'' which comes in the middle of the Spanish alphabet, not at the end, and hence might confuse people about the weight of ``o''. The answer to this has impact on \funref{digit-char-p} and \funref{digit-weight}.}
eql, char=, or char-equal are not necessarily eq.
char< is consistent with the numerical ordering by the predicate < on their code attributes.
13.2.0 28
char=.
Reviewer: Barmar: I wonder if we should say that the ordering may be dependent on the implementation-defined attributes.
13.2.0 29
char-int to the characters.
13.2.0 30
(char<= #\a x #\z) is not a valid way of determining whether or not x is a lowercase character.
Discussion omitted about how the ordering might depend on font information.
13.2.0 25 13.2.0 26 The standard \term{alphanumeric} \term{characters} obey the following partial ordering:Of the standard characters, those which are alphanumeric obey the following partial ordering:
A<B<C<D<E<F<G<H<I<J<K<L<M<N<O<P<Q<R<S<T<U<V<W<X<Y<Z a<b<c<d<e<f<g<h<i<j<k<l<m<n<o<p<q<r<s<t<u<v<w<x<y<z 0<1<2<3<4<5<6<7<8<9 either 9<A or Z<0 either 9<a or z<0This implies that, for standard characters, alphabetic1 ordering holds within each case (uppercase and lowercase), and that the numeric characters as a group are not interleaved with alphabetic characters. However, the ordering or possible interleaving of uppercase characters and lowercase characters is implementation-defined.
The following character names must be present in all conforming implementations:
22.1.4 9
Newline
2.2.2 3The character that represents the division between lines. An implementation must translate between #\Newline, a single-character representation, and whatever external representation(s) may be used.
22.1.4 10
Space
The space or blank character.
The following names are semi-standard; if an implementation supports them, they should be used for the described characters and no others.
Rubout
The rubout or delete character.
22.1.4 11
Page
The form-feed or page-separator character.
22.1.4 12
Tab
The tabulate character.
22.1.4 13
Backspace
The backspace character.
22.1.4 14
Return
The carriage return character.
22.1.4 15
Linefeed
The line-feed character.
In some implementations, one or more of these character names might denote a standard character; for example, #\Linefeed and #\Newline might be the same character in some implementations.
2.2.2 6When the character #\Newline is written to an output file, the implementation must take the appropriate action to produce a line division. This might involve writing out a record or translating #\Newline to a CR/LF sequence. When reading, a corresponding reverse transformation must take place.
\editornote{KMP: This next paragraph is somewhat tentative.
Maybe a glossary term for this would be good if I decide it should stay.
Do reviewers think this concept is worth naming, and is ``encoding'' ok as a name?}%!!!A character is sometimes represented merely by its code, and sometimes by another integer value which is composed from the code and all implementation-defined attributes (in an implementation-defined way that might vary between Lisp images even in the same implementation). This integer, returned by the function char-int, is called the character's “encoding.” There is no corresponding function from a character's encoding back to the character, since its primary intended uses include things like hashing where an inverse operation is not really called for.
2.2.5 1 Discussion of STRING-CHAR deleted.
An implementation must document the character scripts it supports. For each character script supported, the documentation must describe at least the following:
read treats different characters as equivalent must be documented. char-upcase, char-downcase, and the case-sensitive format directives. In particular, for each character with case, whether it is uppercase or lowercase, and which character is its equivalent in the opposite case. char-equal, char-not-equal, char-lessp, char-greaterp, char-not-greaterp, and char-not-lessp. alpha-char-p, lower-case-p, upper-case-p, both-case-p, graphic-char-p, and alphanumericp.
character System Classbase-char Typestandard-char Typeextended-char Typechar=, char/=, char<, char>, char<=, char>=, char-equal, char-not-equal, char-lessp, char-greaterp, char-not-greaterp, char-not-lessp Functioncharacter Functioncharacterp Functionalpha-char-p Functionalphanumericp Functiondigit-char Functiondigit-char-p Functiongraphic-char-p Functionstandard-char-p Functionchar-upcase, char-downcase Functionupper-case-p, lower-case-p, both-case-p Functionchar-code Functionchar-int Functioncode-char Functionchar-code-limit Constant Variablechar-name Functionname-char Function