Initial check in docu
This commit is contained in:
@@ -0,0 +1,249 @@
|
||||
\section{Sections}
|
||||
|
||||
\subsection{unit}
|
||||
The unit section specifies the unit name of the generated source file.
|
||||
The syntax is identical to Object Pascal.
|
||||
|
||||
\subsection{uses}
|
||||
The §uses{...}§ section is used to specify the units which must be
|
||||
included in the interface's uses clause of the generated pascal
|
||||
unit. Every unit name must be terminated by a semicolon. Repeated
|
||||
units are included only once.
|
||||
\begin{verbatim}
|
||||
uses
|
||||
{
|
||||
Classes;
|
||||
Windows;
|
||||
}
|
||||
\end{verbatim}
|
||||
|
||||
|
||||
\subsection{const}
|
||||
The §const{...}§ section is used to specify items that appear in
|
||||
the interface's const clause of the generated pascal unit. The
|
||||
content of this section is copied verbatim into the unit.
|
||||
\begin{verbatim}
|
||||
const
|
||||
{
|
||||
const1 = 12;
|
||||
const2 = ‘FOO’;
|
||||
}
|
||||
\end{verbatim}
|
||||
|
||||
\subsection{type}
|
||||
The §type{...}§ section is used to specify items that appear in
|
||||
the interface's type clause of the generated pascal unit. The
|
||||
content of this section is copied verbatim into the unit.
|
||||
\begin{verbatim}
|
||||
type
|
||||
{
|
||||
TmyType1 = integer;
|
||||
TmyType2 = array [0..16] of TmyType1;
|
||||
}
|
||||
\end{verbatim}
|
||||
|
||||
\subsection{options}
|
||||
The §options{...}§ section contains options for a given grammar
|
||||
element. Options can be defined for lexer/parser classes, rules
|
||||
and subrules.
|
||||
|
||||
\subsection{tokens}
|
||||
If you need to define an ``imaginary'' token (i.e. one that has no
|
||||
corresponding real input symbol) use the §tokens{...}§ section to
|
||||
define them. You can also define literals in this section.
|
||||
|
||||
\begin{verbatim}
|
||||
tokens
|
||||
{
|
||||
"procedure";
|
||||
"function";
|
||||
INTEGER;
|
||||
}
|
||||
\end{verbatim}
|
||||
|
||||
Strings defined in this way are treated just as if you had referenced them in
|
||||
the parser. The formal syntax is:
|
||||
|
||||
\begin{verbatim}
|
||||
tokenSpecification
|
||||
: "tokens"
|
||||
LCURLY
|
||||
(tokenItem SEMI)*
|
||||
RCURLY
|
||||
;
|
||||
|
||||
tokenItem
|
||||
: TOKEN
|
||||
| STRING
|
||||
;
|
||||
\end{verbatim}
|
||||
|
||||
The §tokens{...}§ section is only valid in lexer grammars.
|
||||
|
||||
\subsection{memberdecl}
|
||||
The §memberdecl{...}§ section contains additional member
|
||||
declarations for the grammar class. It allows the expansion of the
|
||||
grammar class with user defined members, so it is not necessary to
|
||||
derive new classes from the generated class to implement
|
||||
additional functionality. The content of this section is copied
|
||||
verbatim into the class declaration of the generated grammar
|
||||
class.
|
||||
\begin{verbatim}
|
||||
memberdecl
|
||||
{
|
||||
procedure proc1;
|
||||
procedure proc2;
|
||||
}
|
||||
\end{verbatim}
|
||||
|
||||
\subsection{memberdef}
|
||||
The §memberdef{...}§ section contains the implementation of the
|
||||
classes' additional functionality. The content of this section is
|
||||
copied verbatim into the implementation part of the generated
|
||||
unit. This section may also contain the initialization and
|
||||
finalization clauses.
|
||||
|
||||
\begin{verbatim}
|
||||
memberdef
|
||||
{
|
||||
procedure TmyClass.proc1;
|
||||
begin
|
||||
...
|
||||
end;
|
||||
|
||||
procedure TmyClass.proc2;
|
||||
begin
|
||||
...
|
||||
end;
|
||||
}
|
||||
\end{verbatim}
|
||||
|
||||
\subsection{parser}
|
||||
Parser rules must be associated with a parser class. Each parser
|
||||
class specification precedes the options, and rule definitions of
|
||||
the parser. Grammar files §.g§ can hold only one class definition.
|
||||
A parser specification in a grammar file looks like:
|
||||
\begin{verbatim}
|
||||
unit myParser;
|
||||
uses... // optional uses {...} section
|
||||
const... // optional const {...} section
|
||||
type... // optional type {...} section
|
||||
|
||||
parser TmyParser;
|
||||
|
||||
options... // optional options {...} section
|
||||
memberdecl... // optional memberdecl {...} section
|
||||
parser rules...
|
||||
memberdef... // optional memberdef {...} section
|
||||
\end{verbatim}
|
||||
|
||||
In the generated code, the parser class results in an Object
|
||||
Pascal class, and the rules become member methods of the class.
|
||||
|
||||
Note, that the content of the §memberdecl{...}§ section is copied
|
||||
verbatim into the class declaration part of the generated parser
|
||||
class while the content of the §memberdef{...}§ section is copied
|
||||
after the implementation of the member rules, so the
|
||||
initialization and finalization clauses of a pascal unit can be
|
||||
placed in the §memberdef{...}§ section.
|
||||
|
||||
\subsection{lexer}
|
||||
To perform lexical analysis, you need to specify a lexer class that describes
|
||||
how to break up the input character stream into a stream of tokens. The syntax
|
||||
is similar to that of a parser class:
|
||||
\begin{verbatim}
|
||||
unit myLexer;
|
||||
uses... // optional uses {...} section
|
||||
const... // optional const {...} section
|
||||
type... // optional type {...} section
|
||||
|
||||
lexer TmyLexer;
|
||||
|
||||
options... // optional options {...} section
|
||||
tokens... // optional tokens {...} section
|
||||
memberdecl... // optional memberdecl {...} section
|
||||
lexer rules...
|
||||
memberdef... // optional memberdef {...} section
|
||||
\end{verbatim}
|
||||
|
||||
Lexical rules contained within a lexer class become member methods in the
|
||||
generated class. A lexer grammar may have a §tokens{...}§ section to specify
|
||||
imaginary tokens and string literals.
|
||||
|
||||
\subsection{rule definitions}
|
||||
The structure of an input stream of atoms is specified by a set of
|
||||
mutually-referenced rules. Each rule has a name and any of the
|
||||
following optional attributes: a scope specifier; a set of
|
||||
arguments; an init-action; a return value; local variable
|
||||
definitions; an exception handler and an alternative or
|
||||
alternatives. Each alternative contains a series of elements that
|
||||
specify what to match and where. Scope can be specified by
|
||||
private, protected, or public keywords. A rule has public scope by
|
||||
default. The basic form of a rule is:
|
||||
\begin{verbatim}
|
||||
(scope) rulename
|
||||
: alternative_1
|
||||
| alternative_2
|
||||
...
|
||||
| alternative_n
|
||||
;
|
||||
\end{verbatim}
|
||||
|
||||
Parameters for a rule can be specified in the following form:
|
||||
\begin{verbatim}
|
||||
rulename [formal parameters] : ... ;
|
||||
\end{verbatim}
|
||||
|
||||
If the rule returns a value, it’s type can be defined with the
|
||||
returns keyword:
|
||||
\begin{verbatim}
|
||||
rulename returns [typename] : ... ;
|
||||
\end{verbatim}
|
||||
|
||||
where §typename§ is a valid Object Pascal type specifier.
|
||||
|
||||
Local variables for a rule can be defined in the §local{...}§ section:
|
||||
|
||||
\begin{verbatim}
|
||||
rule
|
||||
local
|
||||
{
|
||||
foo: integer;
|
||||
bar: string;
|
||||
}
|
||||
\end{verbatim}
|
||||
|
||||
Init-actions are specified before the colon. Init-actions differ from normal
|
||||
actions because they are always executed regardless of guess mode.
|
||||
|
||||
\begin{verbatim}
|
||||
rule
|
||||
{
|
||||
init-action
|
||||
}
|
||||
: ... ;
|
||||
\end{verbatim}
|
||||
|
||||
|
||||
\paragraph{Parser rules} apply structure to a stream of tokens, whereas
|
||||
lexer rules apply structure to a stream of characters. Parser
|
||||
rules, therefore, must not reference cha\-rac\-ter literals.
|
||||
Double-quoted strings in parser rules are considered to be token
|
||||
references. Note: all parser rules must begin with a lowercase
|
||||
letter.
|
||||
|
||||
\paragraph{Lexer rules} defined within a lexer grammar must have a name beginning
|
||||
with an uppercase letter. These rules implicitly match
|
||||
cha\-rac\-ters on the input stream instead of tokens on the token
|
||||
stream. Referenced grammar elements include token references
|
||||
(implicit lexer rule references), cha\-rac\-ters and strings.
|
||||
Lexer rules are processed in the same manner as parser rules, and
|
||||
may also specify arguments and return values. A scope specifier
|
||||
for a lexer rule has special meaning in lexer grammars. In the
|
||||
generated Object Pascal unit, the lexer class has a §nextToken§
|
||||
function which is the interface between the lexer and the parser.
|
||||
This function is synthesized from the public lexer rules. It means
|
||||
that non-public lexer rules don't modify the prediction logic of
|
||||
the lexer. They are usually helper rules. If the lexer grammar has
|
||||
no public rule at all, the §nextToken§ function returns EOF to the
|
||||
parser.
|
||||
Reference in New Issue
Block a user