LALR Parser Generator - Revision history

Thomas Linder Puls: Example template

2018-02-16T12:01:34Z

Example template

← Older revision		Revision as of 14:01, 16 February 2018
Line 377:		Line 377:


	{{Example\| In the Visual Prolog grammar the equal operator "=" is put into the <vpgrm>[t_rel_op]</vpgrm> terminal symbol:		{{Example\|1= In the Visual Prolog grammar the equal operator "=" is put into the <vpgrm>[t_rel_op]</vpgrm> terminal symbol:
	<vipgrm>		<vipgrm>
	terminals		terminals

Thomas Linder Puls: released

2017-08-09T20:46:54Z

released

← Older revision		Revision as of 22:46, 9 August 2017
Line 1:		Line 1:
	~~{{Template:NonReleased}}~~

	Visual Prolog Commercial Edition contains an LALR(1) parser generator in the examples (in the directory '''vipLalrGen''').		Visual Prolog Commercial Edition contains an LALR(1) parser generator in the examples (in the directory '''vipLalrGen''').

Thomas Linder Puls: Visual Prolog 8

2017-06-21T14:32:12Z

Visual Prolog 8

Show changes

Thomas Linder Puls: simplify and correct

2016-02-22T09:37:43Z

simplify and correct

← Older revision		Revision as of 11:37, 22 February 2016
Line 334:		Line 334:
	Details about parsing conflicts can be found in the produced log file.		Details about parsing conflicts can be found in the produced log file.

	A grammar for a certain language can be written in many ways ~~(just like a program with a certain functionality can be written in many ways)~~, and if may often be possible to rewrite a grammar that have conflicts to another one that doesn't have conflicts (but recognizes the same language).		A grammar for a certain language can be written in many ways, and it may often be possible to rewrite a grammar that have conflicts to another one that doesn't have conflicts (but recognizes the same language).

	It is outside the scope of this article to go into details about conflicts and how to resolve them, unfortunately it may require relatively deep understanding of parsing. As mentioned above vipLalrGen is an LALR(1) parser generator like YACC and the like, so there is lots of existing material about the subject "out there".		It is outside the scope of this article to go into details about conflicts and how to resolve them, unfortunately it may require relatively deep understanding of parsing. As mentioned above vipLalrGen is an LALR(1) parser generator like YACC and the like, so there is lots of existing material about the subject "out there".

Thomas Linder Puls: tag-error

2015-02-23T12:27:38Z

tag-error

Show changes

Thomas Linder Puls: error recovery, cursors and comments

2015-02-23T12:26:14Z

error recovery, cursors and comments

Show changes

Thomas Linder Puls: /* Grammar files */ Casing

2015-02-22T13:03:42Z

Grammar files: Casing

← Older revision		Revision as of 15:03, 22 February 2015
Line 70:		Line 70:
	The input <vp>vipLalrGen</vp> is a grammar file. As mentioned the IDE supports token coloring if the extension is vipgrm.		The input <vp>vipLalrGen</vp> is a grammar file. As mentioned the IDE supports token coloring if the extension is vipgrm.

	a grammar file contains a named grammar:		A grammar file contains a named grammar:

	<source lang="vipgrm">		<source lang="vipgrm">
Line 84:		Line 84:
	exp : expression.		exp : expression.
	rules		rules
	exp { mkBinOp(Op, a, b) } ==>		exp { mkBinOp(Op, A, B) } ==>
	exp { a },		exp { A },
	[t_cmp] { Op },		[t_cmp] { Op },
	exp { b }.		exp { B }.

	exp { mkBinOp(Op, a, b) } ==>		exp { mkBinOp(Op, A, B) } ==>
	exp { a },		exp { A },
	[t_power] { Op },		[t_power] { Op },
	exp { b }.		exp { B }.

	exp { mkBinOp(Op, a, b) } ==>		exp { mkBinOp(Op, A, B) } ==>
	exp { a },		exp { A },
	[t_mult] { Op },		[t_mult] { Op },
	exp { b }.		exp { B }.

	exp { mkBinOp(Op, a, b) } ==>		exp { mkBinOp(Op, A, B) } ==>
	exp { a },		exp { A },
	[t_plus] { Op },		[t_plus] { Op },
	exp { b }.		exp { B }.

	exp { E } ==>		exp { E } ==>
Line 163:		Line 163:

	<source lang="vipgrm">		<source lang="vipgrm">
	exp { mkBinOp(Op, a, b) } ==>		exp { mkBinOp(Op, A, B) } ==>
	exp { a },		exp { A },
	[t_cmp] { Op },		[t_cmp] { Op },
	exp { b }.</source>		exp { B }.</source>

	<vp>a</vp> and <vp>b</vp> contains the parse-trees of the two <vp>exp</vp>s and <vp>Op</vp> contains the string of the terminal symbol <vp>t_cmp</vp>. The resulting parse tree is calculated as <vp>mkBinOp(Op, a, b)</vp>.		<vp>A</vp> and <vp>B</vp> contains the parse-trees of the two <vp>exp</vp>s and <vp>Op</vp> contains the string of the terminal symbol <vp>t_cmp</vp>. The resulting parse tree is calculated as <vp>mkBinOp(Op, A, B)</vp>.

	==== Precedence ====		==== Precedence ====
Line 205:		Line 205:
	</source>		</source>

	a precedence declaration states one of the associativites (<vp>nonassoc</vp>, <vp>left</vp> or <vp>right</vp>) followed by a comma separated sequence of terminal symbols and terminated by a dot.		A precedence declaration states one of the associativites (<vp>nonassoc</vp>, <vp>left</vp> or <vp>right</vp>) followed by a comma separated sequence of terminal symbols and terminated by a dot.

	The terminals in a precedence declaration have the same precedence level and associativity. The declarations are stated in increasing precedence (i.e. the first declaration have lowest precedence).		The terminals in a precedence declaration have the same precedence level and associativity. The declarations are stated in increasing precedence (i.e. the first declaration have lowest precedence).

	Given <vp>a [t1] b [t2] c</vp>		Given <vp>A [t1] B [t2] C</vp>

	* If <vp>t1</vp> has higher precedence than <vp>t2</vp> then <vp>a [t1] b</vp> will be reduced to <vp>AB</vp> and then <vp>AB [t2] c</vp> will be reduced.		* If <vp>t1</vp> has higher precedence than <vp>t2</vp> then <vp>A [t1] B</vp> will be reduced to <vp>AB</vp> and then <vp>AB [t2] C</vp> will be reduced.
	* If <vp>t1</vp> has lower precedence than <vp>t2</vp> then <vp>b [t2] c</vp> will be reduced to <vp>BC</vp> and then <vp>a [t1] BC</vp> will be reduced.		* If <vp>t1</vp> has lower precedence than <vp>t2</vp> then <vp>B [t2] C</vp> will be reduced to <vp>BC</vp> and then <vp>A [t1] BC</vp> will be reduced.
	*If <vp>t1</vp> and <vp>t2</vp> have same precedence, then		*If <vp>t1</vp> and <vp>t2</vp> have same precedence, then
	** If they are <vp>left</vp> then <vp>a [t1] b</vp> will be reduced to <vp>AB</vp> and then <vp>AB [t2] c</vp> will be reduced.		** If they are <vp>left</vp> then <vp>A [t1] B</vp> will be reduced to <vp>AB</vp> and then <vp>AB [t2] C</vp> will be reduced.
	** If they are <vp>right</vp> then <vp>b [t2] c</vp> will be reduced to <vp>BC</vp> and then <vp>a [t1] BC</vp> will be reduced.		** If they are <vp>right</vp> then <vp>B [t2] C</vp> will be reduced to <vp>BC</vp> and then <vp>A [t1] BC</vp> will be reduced.
	** If they are <vp>nonassoc</vp> the construction is illegal and the parser will issue s syntax error.		** If they are <vp>nonassoc</vp> the construction is illegal and the parser will issue s syntax error.

Thomas Linder Puls: header level

2015-02-19T15:53:17Z

header level

← Older revision		Revision as of 17:53, 19 February 2015
Line 7:		Line 7:
	The theory of parsers is huge and cannot be covered here. An LALR(1) parser parses from ''Left'' to right, and produces an inverse ''Rightmost'' derivation using 1 ''Look-Ahead'' symbol. See for example [[wikipedia:LALR parser]] for more information.		The theory of parsers is huge and cannot be covered here. An LALR(1) parser parses from ''Left'' to right, and produces an inverse ''Rightmost'' derivation using 1 ''Look-Ahead'' symbol. See for example [[wikipedia:LALR parser]] for more information.

	== Parsing ==		=== Parsing ===

	The purpose of a parser is to validate that an input string fulfills a certain grammar specification, and:		The purpose of a parser is to validate that an input string fulfills a certain grammar specification, and:
Line 17:		Line 17:
	The lexing and the parsing is performed intermixed in a single start-to-end scan of the text (without backtracking).		The lexing and the parsing is performed intermixed in a single start-to-end scan of the text (without backtracking).

	== Parser structure ==		=== Parser structure ===

	The parser of the '''exprEval''' demo can be used as illustration of the parser components and how the overall parsing works.		The parser of the '''exprEval''' demo can be used as illustration of the parser components and how the overall parsing works.
Line 34:		Line 34:
	The directory sub directory/package <vp>expressionLexer</vp> contains the lexical analyzer. It is based on the class <vp>pfc\syntax\lexer_string</vp>, which makes it very easy to implement lexers uses Visual Prolog number, string and comment syntax. Basically the programmer only needs to define things like keywords and operators.		The directory sub directory/package <vp>expressionLexer</vp> contains the lexical analyzer. It is based on the class <vp>pfc\syntax\lexer_string</vp>, which makes it very easy to implement lexers uses Visual Prolog number, string and comment syntax. Basically the programmer only needs to define things like keywords and operators.

	== vipLalrGen ==		=== vipLalrGen ===

	The parser generator itself is in the <vp>vipLalrGen</vp> sub directory (i.e. in '''<examples root>\vipLalrGen\vipLalrGen''', and it should be built before it can be used.		The parser generator itself is in the <vp>vipLalrGen</vp> sub directory (i.e. in '''<examples root>\vipLalrGen\vipLalrGen''', and it should be built before it can be used.
Line 66:		Line 66:
	* If successful: <vp><grammar>.i</vp>, <vp><grammar>.cl</vp>, <vp><grammar>.pro</vp> containing the generated parser		* If successful: <vp><grammar>.i</vp>, <vp><grammar>.cl</vp>, <vp><grammar>.pro</vp> containing the generated parser

	== Grammar files ==		=== Grammar files ===

	The input <vp>vipLalrGen</vp> is a grammar file. As mentioned the IDE supports token coloring if the extension is vipgrm.		The input <vp>vipLalrGen</vp> is a grammar file. As mentioned the IDE supports token coloring if the extension is vipgrm.
Line 118:		Line 118:
	</source>		</source>

	=== nonterminals & rules ===		==== nonterminals & rules ====

	The grammar file (among other) contains <vp>nonterminals</vp> and <vp>rules</vp> sections.		The grammar file (among other) contains <vp>nonterminals</vp> and <vp>rules</vp> sections.
Line 170:		Line 170:
	<vp>a</vp> and <vp>b</vp> contains the parse-trees of the two <vp>exp</vp>s and <vp>Op</vp> contains the string of the terminal symbol <vp>t_cmp</vp>. The resulting parse tree is calculated as <vp>mkBinOp(Op, a, b)</vp>.		<vp>a</vp> and <vp>b</vp> contains the parse-trees of the two <vp>exp</vp>s and <vp>Op</vp> contains the string of the terminal symbol <vp>t_cmp</vp>. The resulting parse tree is calculated as <vp>mkBinOp(Op, a, b)</vp>.

	=== Precedence ===		==== Precedence ====

	The grammar rules in the expression grammar are by themselves ambiguous, in the sense that 3 + 4 * 5 can derived by both these rightmost derivations:		The grammar rules in the expression grammar are by themselves ambiguous, in the sense that 3 + 4 * 5 can derived by both these rightmost derivations:
Line 218:		Line 218:
	** If they are <vp>nonassoc</vp> the construction is illegal and the parser will issue s syntax error.		** If they are <vp>nonassoc</vp> the construction is illegal and the parser will issue s syntax error.

	== Conflicts ==		=== Conflicts ===

	As briefly mentioned above there are situations where the parser generator cannot produce a parser. Briefly speaking the parser generator generates parset tables that in a given situation instructs the parser either to shift the next terminal symbol onto an parser stack or to reduce the top elements of the parser stack using one of the grammar rules (aka production rule).		As briefly mentioned above there are situations where the parser generator cannot produce a parser. Briefly speaking the parser generator generates parset tables that in a given situation instructs the parser either to shift the next terminal symbol onto an parser stack or to reduce the top elements of the parser stack using one of the grammar rules (aka production rule).
Line 230:		Line 230:
	It is outside the scope of this article to go into details about conflicts and how to resolve them, unfortunately it may require relatively deep understanding of parsing. As mentioned above vipLalrGen is an LALR(1) parser generator like YACC and the like, so there is lots of existing material about the subject "out there".		It is outside the scope of this article to go into details about conflicts and how to resolve them, unfortunately it may require relatively deep understanding of parsing. As mentioned above vipLalrGen is an LALR(1) parser generator like YACC and the like, so there is lots of existing material about the subject "out there".

	== External References ==		=== External References ===

	Basic reading is the [[wikipedia:Compilers: Principles, Techniques, and Tools\|"Dragon Book"]].		Basic reading is the [[wikipedia:Compilers: Principles, Techniques, and Tools\|"Dragon Book"]].

	[[Category:Tutorials]]		[[Category:Tutorials]]

Thomas Linder Puls: init

2015-02-19T15:51:44Z

init

New page

Visual Prolog 7.5 Commercial Edition (build 7501+) contains an LALR(1) parser generator in the examples (in the directory '''vipLalrGen'''). The example directory also contains a program '''exprEval''', which uses a generated parser to parse arithmetical expressions.

The parser generator itself also uses such parser to parse grammar files, so it can be seen as another example.

The directory '''$(ProDir)/vip/vipSyntax''' contains a grammar file '''vipSyntax.vipgrm''' defining the Visual Prolog syntax. The directory also contains the corresponding generated files, and all other files necessary to parse Visual Prolog programs. But that is not the topic of this article, it is only mentioned for reference.

The theory of parsers is huge and cannot be covered here. An LALR(1) parser parses from ''Left'' to right, and produces an inverse ''Rightmost'' derivation using 1 ''Look-Ahead'' symbol. See for example [[wikipedia:LALR parser]] for more information.

== Parsing ==

The purpose of a parser is to validate that an input string fulfills a certain grammar specification, and:
* if the grammar is fulfilled: construct a corresponding parse tree.
* if the grammar is not fulfilled: output "syntax error" messages describing the problems.

The overall parsing process consist of splitting the input into lexical elements known as <vp>terminals</vp> and parsing these according to the grammar specification.

The lexing and the parsing is performed intermixed in a single start-to-end scan of the text (without backtracking).

== Parser structure ==

The parser of the '''exprEval''' demo can be used as illustration of the parser components and how the overall parsing works.

The grammar file and the parser components are in the sub directory/package <vp>expressionGrm</vp>.

* <vp>expcessionGrm.vipgrm</vp> the grammar specification.
* <vp>expcessionGrm.i</vp>, <vp>expcessionGrm.cl</vp> and <vp>expcessionGrm.pro</vp> the parser.
* <vp>expressionLexer</vp> contains the lexer.
* <vp>expressionSem</vp> contains a support class for building the resulting parse tree.

<vp>expcessionGrm.i</vp>, <vp>expcessionGrm.cl</vp> and <vp>expcessionGrm.pro</vp> are generated by the <vp>vipLalrGen</vp> program from the grammar specification <vp>expcessionGrm.vipgrm</vp>.

The directory sub directory/package <vp>expressionGrmSem</vp> contains support predicates for the semantic actions in the grammar.

The directory sub directory/package <vp>expressionLexer</vp> contains the lexical analyzer. It is based on the class <vp>pfc\syntax\lexer_string</vp>, which makes it very easy to implement lexers uses Visual Prolog number, string and comment syntax. Basically the programmer only needs to define things like keywords and operators.

== vipLalrGen ==

The parser generator itself is in the <vp>vipLalrGen</vp> sub directory (i.e. in '''<examples root>\vipLalrGen\vipLalrGen''', and it should be built before it can be used.

The '''vipLalrGen''' program will read grammar files and generate LALR(1) parsers as Visual Prolog source code.

<source lang="text">vipLalrGen.exe - LALR parser generator for Visual Prolog

Usage:

vipLalrGen.exe [options] <grammar files>

Options:

@<File> Read options from <File>
-help Displays the help message
-out <OutDir> Generate files in <OutDir> (default: the directory containing the grammar file)
-details Add details to the log file
-nodetails Don't add details to the log file (default)</source>

It is recommended to have grammars in files with extension '''vipgrm'''; the IDE will token color files with that extension.

{{Example|To run vipLalrGen on the grammar file in the '''exprEval''' example from a command console:
<source lang="text">
>cd <example path>\vipLalrGen
>vipLalrGen\Exe\vipLalrGen.exe exprEval\expressionGrm\expressionGrm.vipgrm
OK: exprEval\expressionGrm\expressionGrm.vipgrm
</source>}}
When running vipLalrGen on a grammar file it always produces the file:
* <vp>log/<grammar>.log</vp> containing detailed information about the grammar
* If successful: <vp><grammar>.i</vp>, <vp><grammar>.cl</vp>, <vp><grammar>.pro</vp> containing the generated parser

== Grammar files ==

The input <vp>vipLalrGen</vp> is a grammar file. As mentioned the IDE supports token coloring if the extension is vipgrm.

a grammar file contains a named grammar:

<source lang="vipgrm">
grammar expressionGrm
open expression, expressionGrmSem

nonassoc t_cmp.
left t_plus.
left t_mult.
right t_power.

nonterminals
exp : expression.
rules
exp { mkBinOp(Op, a, b) } ==>
exp { a },
[t_cmp] { Op },
exp { b }.

exp { mkBinOp(Op, a, b) } ==>
exp { a },
[t_power] { Op },
exp { b }.

exp { mkBinOp(Op, a, b) } ==>
exp { a },
[t_mult] { Op },
exp { b }.

exp { mkBinOp(Op, a, b) } ==>
exp { a },
[t_plus] { Op },
exp { b }.

exp { E } ==>
[t_lpar],
exp { E },
[t_rpar].

exp { number(toTerm(real, N)) } ==>
[t_number] { N }.

exp { bool(toTerm(boolean, N)) } ==>
[t_boolean] { N }.

end grammar expressionGrm
</source>

=== nonterminals & rules ===

The grammar file (among other) contains <vp>nonterminals</vp> and <vp>rules</vp> sections.

<vp>nonterminals</vp> sections declares nonterminal symbols and the type of the corresponding parse trees. The nonterminals section above states that <vp>exp</vp> is a nonterminal symbol and that it produces parse trees of the (Visual Prolog) type <vp>expression</vp>.

<vp>rules</vp> sections contains rules that both defines how valid ''derivations'' of nonterminal system looks and how the corresponding parse tree is constructed.

Everything in braces have to do with the parse trees. If we initially disregard it, we only see what have to do with the ''derivations''

<source lang="vipgrm">
rules
exp ==> exp, [t_cmp], exp.

exp ==> exp, [t_power], exp.

exp ==> exp, [t_mult], exp.

exp ==> exp, [t_plus], exp.

exp ==> [t_lpar], exp, [t_rpar].

exp ==> [t_number].

exp ==> [t_boolean].
</source>

The first rule says that from the nonterminal symbol <vp>exp</vp> we can derive <vp>exp</vp> followed by <vp>[t_cmp]</vp> followed by <vp>exp</vp>, where <vp>[t_cmp]</vp> is the terminal symbol <vp>t_cmp</vp>.

{{Example|
Here is a derivation that corresponds to the expression <vp>7 < 5</vp> (assuming that <vp>t_number</vp> are numbers and <vp>t_cmp</vp> are comparison operators):
<source lang="vipgrm">
exp
==> exp, [t_cmp], exp
==> exp, [t_cmp], [t_number]
==> [t_number], [t_cmp], [t_number]</source>
}}

The derivation in the example is a '''rightmost''' derivation, because in each step we derive something from the rightmost nonterminal symbol. An LR parser will make reductions in the inverse order of the derivations in a rightmost derivation. '''LR''' parsing means that we scan tokens from '''L'''eft to right and produce an inverse '''R'''ightmost derivation.

As mentioned the braces describes how to construct a corresponding parse tree. The braces on the left hand side contains a Visual Prolog expression that constructs the node in the parse tree. The braces in the right hand side of the rules defines variable names for the corresponding sub-trees.

Given the rule

<source lang="vipgrm">
exp { mkBinOp(Op, a, b) } ==>
exp { a },
[t_cmp] { Op },
exp { b }.</source>

<vp>a</vp> and <vp>b</vp> contains the parse-trees of the two <vp>exp</vp>s and <vp>Op</vp> contains the string of the terminal symbol <vp>t_cmp</vp>. The resulting parse tree is calculated as <vp>mkBinOp(Op, a, b)</vp>.

=== Precedence ===

The grammar rules in the expression grammar are by themselves ambiguous, in the sense that 3 + 4 * 5 can derived by both these rightmost derivations:

<source lang="vipgrm">
exp
==> exp, [t_add], exp
==> exp, [t_add], exp, [t_mult], exp
==> exp, [t_add], exp, [t_mult], [t_number]
==> exp, [t_add], [t_number], [t_mult], [t_number]
==> [t_number], [t_add], [t_number], [t_mult], [t_number]
</source>

<source lang="vipgrm">
exp
==> exp, [t_mult], exp
==> exp, [t_mult], [t_number]
==> exp, [t_add], exp, [t_mult], [t_number]
==> exp, [t_add], [t_number], [t_mult], [t_number]
==> [t_number], [t_add], [t_number], [t_mult], [t_number]
</source>

The ambiguity is not relevant with regards to whether the expression is a valid expression or not, but the two derivations corresponds to two different parse trees (corresponding to the expressions <vp>(3 + 4) * 5</vp> and <vp>3 + (4 * 5)</vp>, respectively). Obviously, we are interested in a particular parse tree (i.e. the latter).

Moreover the ambiguity in the grammar actually makes it impossible for the parser generator to produce a parser (see next section).

This particular kind of ambiguity can be solved by stating the precedence of the terminal symbols corresponding to the operators:

<source lang="vipgrm">
nonassoc t_cmp.
left t_plus.
left t_mult.
right t_power.
</source>

a precedence declaration states one of the associativites (<vp>nonassoc</vp>, <vp>left</vp> or <vp>right</vp>) followed by a comma separated sequence of terminal symbols and terminated by a dot.

The terminals in a precedence declaration have the same precedence level and associativity. The declarations are stated in increasing precedence (i.e. the first declaration have lowest precedence).

Given <vp>a [t1] b [t2] c</vp>

* If <vp>t1</vp> has higher precedence than <vp>t2</vp> then <vp>a [t1] b</vp> will be reduced to <vp>AB</vp> and then <vp>AB [t2] c</vp> will be reduced.
* If <vp>t1</vp> has lower precedence than <vp>t2</vp> then <vp>b [t2] c</vp> will be reduced to <vp>BC</vp> and then <vp>a [t1] BC</vp> will be reduced.
*If <vp>t1</vp> and <vp>t2</vp> have same precedence, then
** If they are <vp>left</vp> then <vp>a [t1] b</vp> will be reduced to <vp>AB</vp> and then <vp>AB [t2] c</vp> will be reduced.
** If they are <vp>right</vp> then <vp>b [t2] c</vp> will be reduced to <vp>BC</vp> and then <vp>a [t1] BC</vp> will be reduced.
** If they are <vp>nonassoc</vp> the construction is illegal and the parser will issue s syntax error.

== Conflicts ==

As briefly mentioned above there are situations where the parser generator cannot produce a parser. Briefly speaking the parser generator generates parset tables that in a given situation instructs the parser either to shift the next terminal symbol onto an parser stack or to reduce the top elements of the parser stack using one of the grammar rules (aka production rule).

But when calculating the parser table it may turn out that it would both be equally good/bad to shift the next terminal onto the stack and to reduce the stack top. This is a so called shift-reduce conflict. Likewise it can turn out that there are two equally good reductions that could be applied to the top of the parse stack, i.e. a so called reduce-reduce conflict.

Details about parsing conflicts can be found in the produced log file.

A grammar for a certain language can be written in many ways (just like a program with a certain functionality can be written in many ways), and if may often be possible to rewrite a grammar that have conflicts to another one that doesn't have conflicts (but recognizes the same language).

It is outside the scope of this article to go into details about conflicts and how to resolve them, unfortunately it may require relatively deep understanding of parsing. As mentioned above vipLalrGen is an LALR(1) parser generator like YACC and the like, so there is lots of existing material about the subject "out there".

== External References ==

Basic reading is the [[wikipedia:Compilers: Principles, Techniques, and Tools|"Dragon Book"]].

[[Category:Tutorials]]