Lexical Format¶

Characters¶

The text format assigns meaning to source text, which consists of a sequence of characters. Characters are assumed to be represented as valid Unicode (Section 2.4) scalar values.

\begin{array}{r} \begin{array}{llll} source & ::= & {char}^{*} \\ char & ::= & U + 00 | \dots | U + D 7 FF | U + E 000 | \dots | U + 10 FFFF \end{array} \end{array}

Note

While source text may contain any Unicode character in comments or string literals, the rest of the grammar is formed exclusively from the characters supported by the 7-bit ASCII subset of Unicode.

Tokens¶

The character stream in the source text is divided, from left to right, into a sequence of tokens, as defined by the following grammar.

\begin{array}{r} \begin{array}{llll} token & ::= & keyword | u N | s N | f N | string | id | ‘ (’ | ‘) ’ | reserved \\ keyword & ::= & (‘ a ’ | \dots | ‘ z ’) {idchar}^{*} (if occurring as a literal terminal in the grammar) \\ reserved & ::= & (idchar | string)^{+} \end{array} \end{array}

Tokens are formed from the input character stream according to the longest match rule. That is, the next token always consists of the longest possible sequence of characters that is recognized by the above lexical grammar. Tokens can be separated by white space, but except for strings, they cannot themselves contain whitespace.

Keyword tokens are defined either implicitly by an occurrence of a terminal symbol in literal form, such as $‘ keyword ’$ , in a syntactic production of this chapter, or explicitly where they arise in this chapter.

Any token that does not fall into any of the other categories is considered reserved, and cannot occur in source text.

Note

The effect of defining the set of reserved tokens is that all tokens must be separated by either parentheses, white space, or comments. For example, $‘ 0 $ x ’$ is a single reserved token, as is $‘ " a " " b " ’$ . Consequently, they are not recognized as two separate tokens $‘ 0 ’$ and $‘ $ x ’$ , or $" a "$ and $" b "$ , respectively, but instead disallowed. This property of tokenization is not affected by the fact that the definition of reserved tokens overlaps with other token classes.

White Space¶

White space is any sequence of literal space characters, formatting characters, or comments. The allowed formatting characters correspond to a subset of the ASCII format effectors, namely, horizontal tabulation ( $U + 09$ ), line feed ( $U + 0 A$ ), and carriage return ( $U + 0 D$ ).

\begin{array}{r} \begin{array}{llcllll} space & ::= & (‘ ’ | format | comment)^{*} \\ format & ::= & U + 09 | U + 0 A | U + 0 D \end{array} \end{array}

The only relevance of white space is to separate tokens. It is otherwise ignored.

Comments¶

A comment can either be a line comment, started with a double semicolon $‘;; ’$ and extending to the end of the line, or a block comment, enclosed in delimiters $‘ (; ’ \dots ‘;) ’$ . Block comments can be nested.

\begin{array}{r} \begin{array}{llcllll} comment & ::= & linecomment | blockcomment \\ linecomment & ::= & ‘;; ’ {linechar}^{*} (U + 0 A | eof) \\ linechar & ::= & c : char & (if c \neq U + 0 A) \\ blockcomment & ::= & ‘ (; ’ {blockchar}^{*} ‘;) ’ \\ blockchar & ::= & c : char & (if c \neq ‘; ’ \land c \neq ‘ (’) \\ | & ‘; ’ & (if the next character is not ‘) ’) \\ | & ‘ (’ & (if the next character is not ‘; ’) \\ | & blockcomment \end{array} \end{array}

Here, the pseudo token $eof$ indicates the end of the input. The look-ahead restrictions on the productions for $blockchar$ disambiguate the grammar such that only well-bracketed uses of block comment delimiters are allowed.

Note

Any formatting and control characters are allowed inside comments.