[fpc-devel] RIP NoGlobals

[Daniël Mantione]

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