[fpc-devel] RIP NoGlobals

[Hans-Peter Diettrich]

Daniël Mantione schrieb:

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

Right, paradigms are somewhat religious. But as with every religion, I 
only believe what matches my own experience.

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

Experience tells me that projects have reached a dead end, when they 
contain enough unmanageable parts which nobody can explain, and which 
nobody dares to touch any more. Such parts typically reside in 
procedural code, rarely in OOP code.


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

In the concrete case of FPC, the bad use of global variables (for 
context sensitive purposes) has nothing to do with religion. 
Current_module is one of the exceptions, which I consider a state 
variable, eligible for a threadvar. Further variables, which have to be 
changed together with current_module, are only used for optimizations, 
and can be replaced by tmodule members.

My (very raw) measurements didn't indicate any noticeable speed penalty, 
when further variables (even current_scanner) are replaced by indirect 
references to members of tmodule. Like with source files, I assume that 
nowadays existing caches (in both hard- and software) invalidate old 
rules, that the use of shadow and buffer variables can speed up 
execution a lot. This can be different for other (non-x86) machines, 
without such sophisticated caching, where the execution time still is 
predictable from a static analysis of the code (by counting fixed clock 
cycles per instruction).


> * OOP was your goal. Your goal should have been parallelization, OOP
> should have been your tool. There are more tools, like threadvars.

Threadvars have the same problematic properties like global variables: 
the must be initialized and switched properly. Every such variable 
affects the complexity of an application, where it adds a very new 
dimension, not only a percentage. My experience and design principles 
are based on automatons and states, so that OOP is not a must, but fits 
nicely into such a model.

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

Yes and no. The number and polymorphism of data structures is not a 
problem per se. But...

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

...the strictly hierarchical OPL unit dependency system requires much 
coding discipline, and also requires hacks for certain constellations 
<sigh>.

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

ACK.

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

Where do you see 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.

Which interfaces?

When there ever existed something like such an interface, it has been 
broken since long, as can be seen on the comments and copies in ppudump.

> The globals unit has its role. Many symbols are there for a good reason.

Please specify.

When the variables in the globals unit are initialized in other units, 
which are not included by an external tool, they only can contain garbage.

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

You mean something like copying declarations and procedures into 
external tools, to bypass the inclusion of unwanted units?


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

:-)

DoDi