Op Wed, 29 Sep 2010, schreef Hans-Peter Diettrich:
A last note on the NoGlobals branch, and parallel processing in the compiler:
A few comments:
You seem to be reasoning from theory, and mainly OOP theory. In principle
this is good, I have been reasoning from theory in the past as well, and
this helped restructuring sections of the compiler, which we have done
extensively in the past and I have had my share in this. This improved the
robustness of the compiler.
In essence your project was good. There are a few remarks to be made:
* There are more theories (religions?) about how maintainable programs
should be made. For example there is a strong group of programmers who
strongly believes there should be no exceptions to type checking. You
could have started a "refactoring" eliminating typecasts rather than
elimination globals. There is functional programming theory. Each theory
has its merits in it own way, but it would be wrong to say that turning
everything OOP would solve all problems or removing all typecasts will
necessarily make our life easier.
* The Pascal language implemented by FPC
is a mixed procedural/OOP language. Procedural programming has its
strengths and FPC makes use of the potential to mix procedural and OOP.
* Global variables cause problems with parallelization, but that does not
mean the choice for a global variable is a bad idea. Variables like
current_module is used so extensively that they are prime candidates to be
global. In my opinion you have been following the OOP bible a bit too
strict here.
* OOP was your goal. Your goal should have been parallelization, OOP
should have been your tool. There are more tools, like threadvars.
It has been said meny times in this discussion: In a compiler there are
dependencies between a lot of datastrcutures. Handling this effectively is
a challenge. FPC's approach in many places is to put abstract
interdependent objects in a single unit, so these objects can use each
other wherever they want. We then add functionality in other units that
derive from the abstract units. Tsym, Tdef, Tsymtable are in a single
unit. All kinds of symbols, definitions, and symbtables have their own
unit.
I consider this design a strong one, the problem of cyclic dependencies
in the compiler is well controllable. It helps maintenance: I know many
C++ projects where all .cpp files over time started to include all .h
files. In FPC, if you notice you can't access current_module from the
current unit, you know you are doing something wrong.
You seemed to have trouble with this model, rather than embrace it and use
it to your advantage, you started to break things apart and change the
dependencies. As expected this caused you a dependency nightmare,
introducing what you tried to eliminate with the better design: You wanted
clear interfaces between certain parts of the compiler, but you did end up
breaking interfaces external tools can use, and fixing them became beyond
any hope.
The globals unit has its role. Many symbols are there for a good reason.
There can be good reason for moving symbols out of it, if you do so, first
try to understand why that symbol is there, and avoid changes in unit
dependencies at all costs.
Above all: You can get far with theory. FPC has a practical and pragmatic
code base but I dare to say it has a theoretically sound base design. New
theory can be a solution for practical problems but implementation of it
requires of new practical compromises to be made. For performance, memory
use or historic reasons, or maybe even because the theory can't catch 100%
of the possible situations (there are even some goto statements in the
compiler).
Nevertheless, you have gotten a lot of knowledge of the compiler, and
this project makes me optimistic you can become a good compiler developer.
Daniël
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
