Introdução ao Desenvolvimento de Compiladores - Revision history

Root at 20:57, 5 June 2023

2023-06-05T20:57:18Z

← Older revision		Revision as of 20:57, 5 June 2023
Line 2:		Line 2:
	{{NAVCompiladores}}		{{NAVCompiladores}}

	Our ~~approach to~~ compiler development ~~follows~~ the classical structure ~~based on a workflow that starts~~ with lexical analysis~~, followed by~~ syntactic analysis, semantic analysis, and code generation. ~~The mentioned steps are based on~~ two code generators (one for creating the scanner and another for ~~creating~~ the syntactic parser) and on modules manually ~~written~~ by the programmer.		Our compiler development approach adopts the classical structure, beginning with lexical analysis and moving through syntactic analysis, semantic analysis, and finally code generation. This process utilizes two code generators -- one for creating the scanner and another for developing the syntactic parser -- and leverages modules manually crafted by the programmer.

	~~Even though~~ we ~~use~~ the ~~classical~~ versions of the scanner and parser generators (Flex and BYACC), we ~~do not use the~~ C ~~language~~. ~~Rather, we use~~ C++~~. Furthermore, we do not limit ourselves to switching~~ languages and ~~programming a number of~~ classes. ~~We make~~ full ~~use~~ of object-oriented programming and ~~structures driven by~~ design patterns to ~~achieve~~ a compiler that is ~~simultaneously cleanly~~ organized and ~~easy~~ to ~~understand and change~~. These are ~~crucial aspects, both~~ in ~~what concerns~~ programming effort and ~~didactic~~ objectives.		While we adhere to the traditional versions of the scanner and parser generators (Flex and BYACC), we transition from C to C++. Our usage of C++ extends beyond merely swapping languages and scripting several classes. Instead, we exploit the full potential of object-oriented programming (OOP) and design patterns, leading to a compiler that is organized in a logical, user-friendly manner, and is amenable to modifications. These features are paramount in terms of programming effort and pedagogical objectives.

	== ~~Regarding~~ C++ ==		== A Case for C++ ==

	~~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.		Employing C++ not only upgrades the quality of C but also allows the native application of OOP architecture principles. Though these principles could be implemented in C, it would entail increased development complexities. Thus, our interest isn't confined to recompiling old C code with a C++ compiler and leaving the outcome to fate. Instead, the incorporation of C++ is designed to impact every facet of compiler development, ranging from the comprehensive organization of the compiler to the composition 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~~.		The decision to use C++ isn't solely about selecting a programming language; it's also about determining the authorship of the compiler code. If for a human programmer, using C++ is merely a competence issue, tools that generate part of the compiler's code need meticulous selection to ensure the produced code operates as anticipated.

	~~Some of the most common~~ compiler development support tools ~~already support C++ natively. This is the case of~~ the Flex lexical ~~analyser or~~ the 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++.		Several widely-used compiler development support tools, such as the Flex lexical analyzer and the Bison parser generator, natively support C++. Conversely, some tools, like Berkeley YACC (BYACC), only support C. In the former scenario, the generated code and the objects it aids merely need integration into the architecture. In the latter scenario, additional adaptations might be necessary, performed either by the programmer or via specialized wrappers. Despite being C code, BYACC-generated parsers, as we will see, are relatively straightforward to adapt to C++.

	== ~~Regarding~~ Design Patterns ==		== The Role of Design Patterns ==

	~~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.		Transitioning from fundamental OOP principles to the realm of design patterns may seem like a small leap, but it brings substantial advantages. Effective use of select design patterns -- particularly, but not limited to, the Composite and Visitor design patterns -- results in a more robust compiler and a streamlined development process.

	[[category:Compiladores]]		[[category:Compiladores]]
	[[category:Ensino]]		[[category:Ensino]]
	[[en:Introduction to Compiler Development]]		[[en:Introduction to Compiler Development]]

Root at 13:16, 13 April 2015

2015-04-13T13:16:41Z

← Older revision		Revision as of 13:16, 13 April 2015
Line 2:		Line 2:
	{{NAVCompiladores}}		{{NAVCompiladores}}

	Our approach to compiler development follows the classical structure based on a ~~airflow~~ that starts with lexical analysis, followed by syntactic analysis, semantic analysis and code generation. The mentioned steps are based on two code generators (one for creating the scanner and another ~~fire~~ creating the syntactic parser) and on modules manually written by the programmer.		Our approach to compiler development follows the classical structure based on a workflow that starts with lexical analysis, followed by syntactic analysis, semantic analysis, and code generation. The mentioned steps are based on two code generators (one for creating the scanner and another for creating the syntactic parser) and on modules manually written by the programmer.

	Even though we use the classical versions of the scanner and parser generators (Flex and BYACC), we do not use the C language. Rather, we use C++. Furthermore, we do limit ourselves to switching languages and programming a number of classes. We make full use of object-oriented programming and structures driven by design patterns to achieve a compiler that is simultaneously cleanly organized and easy to understand and change. These are crucial aspects, both in what concerns programming effort and ~~the~~ didactic objectives.		Even though we use the classical versions of the scanner and parser generators (Flex and BYACC), we do not use the C language. Rather, we use C++. Furthermore, we do not limit ourselves to switching languages and programming a number of classes. We make full use of object-oriented programming and structures driven by design patterns to achieve a compiler that is simultaneously cleanly organized and easy to understand and change. These are crucial aspects, both in what concerns programming effort and didactic objectives.

	== Regarding C++ ==		== Regarding C++ ==
Line 10:		Line 10:
	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 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.		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++.
			Some of the most common compiler development support tools already support C++ natively. This is the case of the Flex lexical analyser or the 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++.

	== Regarding Design Patterns ==		== Regarding Design Patterns ==

Root: /* Regarding C++ */

2012-03-16T00:06:16Z

Regarding C++

← Older revision		Revision as of 00:06, 16 March 2012
Line 8:		Line 8:
	== Regarding C++ ==		== Regarding C++ ==

	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 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.		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.

Root at 00:01, 16 March 2012

2012-03-16T00:01:14Z

← Older revision		Revision as of 00:01, 16 March 2012
Line 1:		Line 1:
	__NOTOC__		__NOTOC__
	{{NAVCompiladores}}		{{NAVCompiladores}}
	== Regarding C++ ~~and Pattern-Oriented Programming~~ ==
			Our approach to compiler development follows the classical structure based on a airflow that starts with lexical analysis, followed by syntactic analysis, semantic analysis and code generation. The mentioned steps are based on two code generators (one for creating the scanner and another fire creating the syntactic parser) and on modules manually written by the programmer.

			Even though we use the classical versions of the scanner and parser generators (Flex and BYACC), we do not use the C language. Rather, we use C++. Furthermore, we do limit ourselves to switching languages and programming a number of classes. We make full use of object-oriented programming and structures driven by design patterns to achieve a compiler that is simultaneously cleanly organized and easy to understand and change. These are crucial aspects, both in what concerns programming effort and the didactic objectives.

			== Regarding C++ ==

	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 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.
Line 7:		Line 12:
	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.		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++.		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++.

			== Regarding Design Patterns ==

	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.

Root at 18:06, 26 June 2010

2010-06-26T18:06:35Z

← Older revision		Revision as of 18:06, 26 June 2010
Line 1:		Line 1:
	__NOTOC__		__NOTOC__
			{{NAVCompiladores}}
	== Regarding C++ and Pattern-Oriented Programming ==		== Regarding C++ and Pattern-Oriented Programming ==

Root at 18:29, 15 November 2008

2008-11-15T18:29:45Z

← Older revision		Revision as of 18:29, 15 November 2008
Line 9:		Line 9:
	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.

	[[category:~~Compilers~~]]		[[category:Compiladores]]
	[[category:~~Teaching~~]]		[[category:Ensino]]
	[[en:Introduction to Compiler Development]]		[[en:Introduction to Compiler Development]]

Root: Introduction to Compiler Development moved to Introdução ao Desenvolvimento de Compiladores

2008-11-15T17:00:58Z

Introduction to Compiler Development moved to Introdução ao Desenvolvimento de Compiladores

← Older revision	Revision as of 17:00, 15 November 2008
(No difference)

Root at 17:00, 15 November 2008

2008-11-15T17:00:27Z

← Older revision		Revision as of 17:00, 15 November 2008
Line 11:		Line 11:
	[[category:Compilers]]		[[category:Compilers]]
	[[category:Teaching]]		[[category:Teaching]]
	[[pt:~~Introdução ao Desenvolvimento de Compiladores~~]]		[[en:Introduction to Compiler Development]]

Root at 17:00, 15 November 2008

2008-11-15T17:00:04Z

← Older revision		Revision as of 17:00, 15 November 2008
Line 11:		Line 11:
	[[category:Compilers]]		[[category:Compilers]]
	[[category:Teaching]]		[[category:Teaching]]
			[[pt:Introdução ao Desenvolvimento de Compiladores]]

Root at 14:58, 16 March 2008

2008-03-16T14:58:06Z

← Older revision		Revision as of 14:58, 16 March 2008
Line 1:		Line 1:
	__NOTOC__		__NOTOC__
	~~{{TOCright}}~~
	== Regarding C++ and Pattern-Oriented Programming ==		== Regarding C++ and Pattern-Oriented Programming ==