Xtext的parser过程

Basically parsing can be separated in the following phases.

1. Lexing
2. Parsing
3. Linking
4. Validation

There are four different possible cardinalities:

1. exactly one (the default, no operator)
2. zero or one (operator ?)
3. zero or more (operator *)
4. one or more (operator +)

terminal rule vs parser rules vs Data Type Rules vs Enum Rules

1. terminal rule
   In the first stage called lexing, a sequence of characters (the text input) is transformed into a sequence of so-called tokens. In this context, a token is sort of a strongly typed part or region of the input sequence. It consists of one or more characters and is matched by a particular terminal rule or keyword and therefore represents an atomic symbol. Terminal rules are also referred to as token rules or lexer rules. There is an informal naming convention that names of terminal rules are all upper-case.

terminal ID: 
    ('^')?('a'..'z'|'A'..'Z'|'_') ('a'..'z'|'A'..'Z'|'_'|'0'..'9')*; 

1. parser rule
   a parser rule – contrary to a terminal rule – does not produce a single atomic terminal token, but a tree of non-terminal and terminal tokens. They lead to a so-called parse tree (in Xtext it is also referred as node model). Furthermore, parser rules are handled as kind of a building plan for the creation of the EObjects that form the semantic model (the linked abstract syntax tree or AST). Due to this fact, parser rules are also called production or EObject rules.

Assignments:

DataType:
    'datatype' name = ID;

相当于 DataType dt = new DataType(); dt.name = ID;

1. Data Type Rules
   Note that rules that do not call other parser rules and do neither contain any actions nor assignments are considered to be data type rules, and the data type EString is implied if none has been explicitly declared.

Value converters are used to transform the parsed string to the actually returned data type value.

QualifiedName returns ecore::EString: 
    ID ('.' ID)*;