Valid Patterns for Tokens (original) (raw)

ANSI Common Lisp 2 Syntax 2.3 Interpretation of Tokens

2.3.5 Valid Patterns for Tokens

The valid patterns for tokens are summarized in the next figure.

Valid patterns for tokens

Note that nnnnn has number syntax, neither xxxxx nor ppppp has number syntax, and aaaaa has any syntax.

A summary of rules concerning package markers follows. In each case, examples are offered to illustrate the case; for presentational simplicity, the examples assume that the readtable case of the current readtable is :upcase.

• 1. If there is a single package marker, and it occurs at the beginning of the_token_, then the token is interpreted as a symbol in the keyword package. It also sets the symbol-value of the newly-created symbol to that same symbol so that the symbol will self-evaluate.
  For example, :bar, when read, interns BAR as an external symbol in the keyword package.
• 2. If there is a single package marker not at the beginning or end of the_token_, then it divides the token into two parts. The first part specifies a package; the second part is the name of an _external symbol_available in that package.
  For example, foo:bar, when read, looks up BAR among the external symbols of the package named FOO.
• 3. If there are two adjacent package markers not at the beginning or end of the_token_, then they divide the token into two parts. The first part specifies a package; the second part is the name of a symbol within that package (possibly an internal symbol).
  For example, foo::bar, when read, interns BAR in the package named FOO.
• 4. If the token contains no package markers, and does not have potential number syntax, then the entire token is the name of the symbol. The symbol is looked up in the current package.
  For example, bar, when read, interns BAR in the current package.
• 5. The consequences are unspecified if any other pattern of _package markers_in a token is used. All other uses of package markers within names of _symbols_are not defined by this standard but are reserved for implementation-dependent use.

For example, assuming the readtable case of the current readtable is :upcase,editor:buffer refers to the _external symbol_named BUFFER present in the package named editor, regardless of whether there is a symbol named BUFFER in the current package. If there is no package namededitor, or if no symbol named BUFFERis present in editor, or if BUFFER is not exported byeditor, the reader signals a correctable error. If editor::buffer is seen, the effect is exactly the same as reading buffer with the editor package being the current package.