Difference between revisions of "Introdução ao Desenvolvimento de Compiladores"

From Wiki**3

Line 8: Line 8:
  
 
Going beyond basic OO principles into the world of design patterns is just a small step, but one that contributes much of the overall gains in this change: indeed, effective use of a few choice design patterns -- especially, but not necessarily limited to, the ''composite'' and ''visitor'' design patterns -- contributes to a much more robust compiler and a much easier development process.
 
Going beyond basic OO principles into the world of design patterns is just a small step, but one that contributes much of the overall gains in this change: indeed, effective use of a few choice design patterns -- especially, but not necessarily limited to, the ''composite'' and ''visitor'' design patterns -- contributes to a much more robust compiler and a much easier development process.
 
== Organization ==
 
 
This text parallels both the structure and development process of a compiler. Thus, the first part deals with lexical analysis, or by a different name, with the morphological analysis of the language being recognized. The second part presents syntax analysis in general and LALR(1) parsers in particular.  The fourth part is dedicated to semantic analysis and the deep structure of a program as represented by a languistic structure. Semantic processing also covers code generation, translation, interpretation, as well as the other processes that use similar development processes.
 
 
Regarding the appendices, they present the code used throught the document. In particular, detailed descriptions of each hierarchy are presented. Also presented is the structure of the final compiler, in terms of code: both the code developed by the compiler developer, and the support code for compiler development and final program execution.
 

Revision as of 16:52, 16 March 2008

Regarding C++ and Pattern-Oriented Programming

Using C++ is not only a way of ensuring a "better C", but also a way of being able to use OO architecture principles in a native environment (the same principles could have been applied to C development, at the cost of increased development difficulties). Thus, we are not interested only in taking a C++ compiler, our old C code and "hope for the best". Rather, using C++ is intended to impact every step of compiler development, from the organization of the compiler as a whole to the makeup of each component.

Using C++ is not only a decision of what language to use to write the code: it is also a matter of who or what writes the compiler code. If for a human programmer using C++ is just a matter of competence, tools that generate some of the compiler's code must be chosen carefully so that the code they generate works as expected. Some of the most common compiler development support tools already support C++ natively. This is the case of the GNU Flex lexical analyser or the GNU Bison parser generator. Other tools, such as Berkeley YACC (BYACC) support only C. In the former case, the generated code and the objects it supports have only to be integrated into the architecture; in the latter case, further adaptation may be needed, either by the programmer or through specialized wrappers. BYACC-generated parsers, in particular, as will be seen, although they are C code, are simple to adapt to C++.

Going beyond basic OO principles into the world of design patterns is just a small step, but one that contributes much of the overall gains in this change: indeed, effective use of a few choice design patterns -- especially, but not necessarily limited to, the composite and visitor design patterns -- contributes to a much more robust compiler and a much easier development process.