2.1 Character Set
This Reference Manual output has not been verified, and may contain omissions or errors. Report any problems on the tracking issue
The character repertoire for the text of an Ada program consists of the entire coding space described by the ISO/IEC 10646:2020 Universal Coded Character Set. This coding space is organized in planes, each plane comprising 65536 characters.
It is our intent to follow the terminology of ISO/IEC 10646:2020 where appropriate, and to remain compatible with the character classifications defined in A.3, “Character Handling”.
Syntax
Paragraphs 2 and 3 were deleted.
A character is defined by this Reference Manual for each cell in the coding space described by ISO/IEC 10646:2020, regardless of whether or not ISO/IEC 10646:2020 allocates a character to that cell.
Static Semantics
4/5The coded representation for characters is implementation defined [(it can be a representation that is not defined within ISO/IEC 10646:2020)]. A character whose relative code point in its plane is 16#FFFE# or 16#FFFF# is not allowed anywhere in the text of a program. The only characters allowed outside of comments are those in categories other_format, format_effector, and graphic_character.
The coded representation for the text of an Ada program.
Note that this rule doesn't really have much force, since the implementation can represent characters in the source in any way it sees fit. For example, an implementation could simply define that what seems to be an other_private_use character is actually a representation of the space character.
The semantics of an Ada program whose text is not in Normalization Form C (as defined by Clause 22 of ISO/IEC 10646:2020) is implementation defined.
The semantics of an Ada program whose text is not in Normalization Form C.
In particular, an implementation can reject such program source. It is easy during lexical analysis to reject source that contains any code point not present in Normalization Form C. Portable programs should always be encoded in Normalization Form C.
Normalization Form C ensures that all source is in a unique format; it eliminates ambiguities and security issues potentially caused by source using unusual sequences of characters. Note that WC3 (the Internet standards group) recommends that all Internet content be in Normalization Form C. We don't require this as there is a potentially significant cost to checking this (just rejecting unallowed code points is not enough), and some implementations may need to be interoperable with tools that produce unnormalized text.
The description of the language definition in this document uses the character properties General Category, Simple Uppercase Mapping, Uppercase Mapping, and Special Case Condition of the documents referenced by Clause 2 of ISO/IEC 10646:2020. The actual set of graphic symbols used by an implementation for the visual representation of the text of an Ada program is not specified.
The “documents referenced” means Unicode, Chapter 4. See the Discussion after the the character categorization definition for a source for machine-readable definitions of these properties.
Characters are categorized as follows:
Our character classification considers that the cells not allocated in ISO/IEC 10646:2020 are graphic characters, except for those whose relative code point in their plane is 16#FFFE# or 16#FFFF#. This seems to provide the best compatibility with future versions of ISO/IEC 10646, as future characters can already be used in Ada character and string literals.
- This paragraph was deleted.
letter_uppercase- Any character whose General Category is defined to be “Letter, Uppercase”.
letter_lowercase- Any character whose General Category is defined to be “Letter, Lowercase”.
letter_titlecase- Any character whose General Category is defined to be “Letter, Titlecase”.
letter_modifier- Any character whose General Category is defined to be “Letter, Modifier”.
letter_other- Any character whose General Category is defined to be “Letter, Other”.
mark_non_spacing- Any character whose General Category is defined to be “Mark, Non-Spacing”.
mark_spacing_combining- Any character whose General Category is defined to be “Mark, Spacing Combining”.
number_decimal- Any character whose General Category is defined to be “Number, Decimal”.
number_letter- Any character whose General Category is defined to be “Number, Letter”.
punctuation_connector- Any character whose General Category is defined to be “Punctuation, Connector”.
other_format- Any character whose General Category is defined to be “Other, Format”.
separator_space- Any character whose General Category is defined to be “Separator, Space”.
separator_line- Any character whose General Category is defined to be “Separator, Line”.
separator_paragraph- Any character whose General Category is defined to be “Separator, Paragraph”.
format_effector- The characters whose code points are 16#09# (CHARACTER TABULATION), 16#0A# (LINE FEED), 16#0B# (LINE TABULATION), 16#0C# (FORM FEED), 16#0D# (CARRIAGE RETURN), 16#85# (NEXT LINE), and the characters in categories
separator_lineandseparator_paragraph.
ISO/IEC 10646:2003 does not define the names of control characters, but rather refers to the names defined by ISO/IEC 6429:1992. These are the names that we use here.
other_control- Any character whose General Category is defined to be “Other, Control”, and which is not defined to be a
format_effector. 13.2/2 other_private_use- Any character whose General Category is defined to be “Other, Private Use”.
other_surrogate- Any character whose General Category is defined to be “Other, Surrogate”.
graphic_character- Any character that is not in the categories
other_control,other_private_use,other_surrogate,format_effector, and whose relative code point in its plane is neither 16#FFFE# nor 16#FFFF#.
We considered basing the definition of lexical elements on Annex A of ISO/IEC TR 10176 (4th edition), which lists the characters which should be supported in identifiers for all programming languages, but we finally decided against this option. Note that it is not our intent to diverge from ISO/IEC TR 10176, except to the extent that ISO/IEC TR 10176 itself diverges from ISO/IEC 10646:2003 (which is the case at the time of this writing [January 2005]).
More precisely, we intend to align strictly with ISO/IEC 10646:2003. It must be noted that ISO/IEC TR 10176 is a Technical Report while ISO/IEC 10646:2003 is a Standard. If one has to make a choice, one should conform with the Standard rather than with the Technical Report. And, it turns out that one must make a choice because there are important differences between the two:
- ISO/IEC TR 10176 is still based on ISO/IEC 10646:2000 while ISO/IEC 10646:2003 has already been published for a year. We cannot afford to delay the adoption of our amendment until ISO/IEC TR 10176 has been revised.
- There are considerable differences between the two editions of ISO/IEC 10646, notably in supporting characters beyond the BMP (this might be significant for some languages, e.g. Korean).
- ISO/IEC TR 10176 does not define case conversion tables, which are essential for a case-insensitive language like Ada. To get case conversion tables, we would have to reference either ISO/IEC 10646:2003 or Unicode, or we would have to invent our own.
For the purpose of defining the lexical elements of the language, we need character properties like categorization, as well as case conversion tables. These are mentioned in ISO/IEC 10646:2003 as useful for implementations, with a reference to Unicode. Machine-readable tables are available on the web at URLs:
http://www.unicode.org/Public/UCD/latest/ucd/UnicodeData.txt
http://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt
with an explanatory document found at URL:
The actual text of the standard only makes specific references to the corresponding clauses of ISO/IEC 10646, not to Unicode.
The following names are used when referring to certain characters (the first name is that given in ISO/IEC 10646:2020):
This table serves to show the correspondence between ISO/IEC 10646:2020 names and the graphic symbols (glyphs) used in this document. These are the characters that play a special role in the syntax of Ada.
graphic symbol
"
#
&
'
(
)
*
+
,
–
.
@
name
quotation mark
number sign
ampersand
apostrophe, tick
left parenthesis
right parenthesis
asterisk, multiply
plus sign
comma
hyphen-minus, minus
full stop, dot, point
commercial at, at sign
graphic symbol
:
;
<
=
>
_
|
/
!
%
[
]
name
colon
semicolon
less-than sign
equals sign
greater-than sign
low line, underline
vertical line
solidus, divide
exclamation point
percent sign
left square bracket
right square bracket
Implementation Requirements
16/3An Ada implementation shall accept Ada source code in UTF-8 encoding, with or without a BOM (see A.4.11), where every character is represented by its code point. The character pair CARRIAGE RETURN/LINE FEED (code points 16#0D# 16#0A#) signifies a single end of line (see 2.2); every other occurrence of a format_effector other than the character whose code point position is 16#09# (CHARACTER TABULATION) also signifies a single end of line.
This is simply requiring that an Ada implementation be able to directly process the ACATS, which is provided in the described format. Note that files that only contain characters with code points in the first 128 (which is the majority of the ACATS) are represented in the same way in both UTF-8 and in "plain" string format. The ACATS includes a BOM in files that have any characters with code points greater than 127. Note that the BOM contains characters not legal in Ada source code, so an implementation can use that to automatically distinguish between files formatted as plain Latin-1 strings and UTF-8 with BOM.
We allow line endings to be both represented as the pair CR LF (as in Windows and the ACATS), and as single format_effector characters (usually LF, as in Linux), in order that files created by standard tools on most operating systems will meet the standard format. We specify how many line endings each represent so that compilers use the same line numbering for standard source files.
This requirement increases portability by having a format that is accepted by all Ada compilers. Note that implementations can support other source representations, including structured representations like a parse tree.
Implementation Permissions
17/3The categories defined above, as well as case mapping and folding, may be based on an implementation-defined version of ISO/IEC 10646 (2003 edition or later).
The exact categories, case mapping, and case folding chosen affects identifiers, the result of '[[Wide_]Wide_]Image, and packages Wide_Characters.Handling and Wide_Wide_Characters.Handling.
This permission allows implementations to upgrade to using a newer character set standard whenever that makes sense, rather than having to wait for the next Ada Standard. But the character set standard used cannot be older than ISO/IEC 10646:2003 (which is essentially similar to Unicode 4.0).
NOTE The characters in categories other_control, other_private_use, and other_surrogate are only allowed in comments.
Extensions to Ada 83
Ada 95 allows 8-bit and 16-bit characters, as well as implementation-specified character sets.
Wording Changes from Ada 83
The syntax rules in this subclause are modified to remove the emphasis on basic characters vs. others. (In this day and age, there is no need to point out that you can write programs without using (for example) lower case letters.) In particular, character (representing all characters usable outside comments) is added, and basic_graphic_character, other_special_character, and basic_character are removed. Special_character is expanded to include Ada 83's other_special_character, as well as new 8-bit characters not present in Ada 83. Ada 2005 removes special_character altogether; we want to stick to ISO/IEC 10646:2003 character classifications. Note that the term “basic letter” is used in A.3, “Character Handling” to refer to letters without diacritical marks.
Extensions to Ada 95
Program text can use most characters defined by ISO-10646:2003. This subclause has been rewritten to use the categories defined in that Standard. This should ease programming in languages other than English.
Inconsistencies With Ada 2005
An implementation is allowed (but not required) to use a newer character set standard to determine the categories, case mapping, and case folding. Doing so will change the results of attributes '[[Wide_]Wide_]Image and the packages [Wide_]Wide_Characters.Handling in the case of a few rarely used characters. (This also could make some identifiers illegal, for characters that are no longer classified as letters.) This is unlikely to be a problem in practice. Moreover, truly portable Ada 2012 programs should avoid using in these contexts any characters that would have different classifications in any character set standards issued since 10646:2003 (since the compiler can use any such standard as the basis for its classifications).
Wording Changes from Ada 2005
Clarified that only characters in the categories defined here are allowed in the source of an Ada program. This was clear in Ada 95, but Amendment 1 dropped the wording instead of correcting it.
A standard source representation is defined that all compilers are expected to process. Since this is the same format as the ACATS, it seems unlikely that there are any implementations that don't meet this requirement. Moreover, other representations are still permitted, and the "impossible or impractical" loophole (see 1.1.3) can be invoked for any implementations that cannot directly process the ACATS.
Wording Changes from Ada 2012
The interpretation of Ada source that is in Normalization Form C but not in Normalization Form KC is no longer implementation-defined. This change could potentially change the meaning of a program for a compiler that normalized all program source to Normalization Form KC before processing it. We don't document this as an inconsistency as such handling was previously implementation defined (so any such code was already defined to be not portable), and we're not aware of any compiler that normalized source code (so we don't expect to see this problem in the real world).