[fpc-other] Fork

[Hans-Peter Diettrich]

Adem schrieb:

> 1) In the fpc-devel I have read quite a few arguments that FPC is 
> production quality and no significant changes can be afforded to that code.

This should have been stated much earlier, before I ever started to 
think about refactoring the compiler :-(

> While I sympathize with what that implies, it also means that, 
> structurally, FPC is more or less frozen --except for very small 
> incremental alterations, there isn't much that can be done with/to it.
> 
> That brings me to this remark by DoDi: "Unfortunately some restrictions 
> apply to the possible changes to the original code, when we want to stay 
> in sync with the SVN trunk."
> 
> I am not at all sure that this is the way to go about it. It is very 
> likely that the needed changes will soon amount to a shape that will 
> make it impossible to stay in sync with the FPC trunk.

Since parts of the compiler already are OO, it may be no problem to 
replace the implemenations of entire classes, provided that their 
functionality is documented - see the thread about the hash tables. 
Syncing problems arise for the code that implements the interaction, or 
higher-level use of the base classes, where the dependencies and order 
of method calls is quite obscure in many cases, and must follow the 
original code perfectly.

> So, I think it would be more sensible/rational to remove this 
> artificial/unsustainable restriction/desire and decide to call this a 
> proper fork for a new version which may or may not be source-mergeable 
> with the FPC trunk.

I want to preserve those parts of the code, that may be subject to 
further trunk evolution, as kind of an (external) library - with a 
somewhat strange looking implementation.

Herefore I'll try to leave those obscure pieces of code in place, i.e. 
in the original units, and only insert additional procedure declarations 
around the identified functional code blocks (procedure header, begin 
... end;). Most such procedures will become methods, so that the local 
variables of the original code can become class/object members, and no 
further declarations or changes to the separated code have to be 
inserted into the original code. Other parts of the code, which become 
unused (old procedure declarations...), can survive as comments, so that 
SVN or Git has good chances to merge any updates from the FPC trunk.

> 2) As it is, FPC codebase represents a very high barrier of entry for 
> the uninitiated, drastically reducing any chances of outsiders coming in 
> and contributing.
> 
> To help with that, I'd like to see the new FPC to be functionally as 
> modularized as possible with sufficiently clear boundaries between each 
> so that people can work on parts without having to know and worry about 
> the whole thing all the time.

+1

> I can hear the 'speed arguments' (that, doing this would lower the speed 
> of compilation etc.) but I am yet to be convinced; plus, if I had to 
> choose between sacrificing a few percent on raw performance and the ease 
> of maintainability, I'll always go for the ease of maintainability.

+1

I'm not sure about the speed impact of refactoring - the result may 
become even faster, by optimization at an higher abstraction level. In 
the non-production fork we also can drop certain requirements, that only 
apply to small machines (little RAM, no caches...). According changes 
may prevent the immediate use of this compiler version on such small 
machines, but that's acceptable since cross-compilation still can be 
used for such cases.


> 3) Alternative parsers. I have read all the objections about this. Yes, 
> it may not solve every single problem. Yes, it will not mean FPC will 
> take over GCC. Yes, not everyone need this functionality. Etc. Etc.
> 
> But, all these seem to ignore one simple fact: Object Pascal (OP) is not 
> a widely used language. A lot of code that is out there is in some other 
> language. Which means, OP developers have either to reinvent most wheels 
> by rewriting the code they need (even though it is readily available in 
> some other language) or try to convert that code into OP.

I'm not sure about the real-life use of such mixed-language code. When 
parts of the code require knowledge of other languages, and is not 
understood by the mainstream coder, such unreadable code could reside in 
(external, binary) modules as well. Nonetheless it's desireable, for the 
sake of integration, that such code is compiled for compatibility with 
the FPC environment (RTL...), so that it can be linked into any OPL 
application, package or library.

> All this is not only a major waste of time, sometimes it requires 
> extensive knowledge of that language.
> 
> So, IMO, anything that helps using that large amount of code base can 
> only be GOOD THING even if it isn't perfect all the time.

This was the goal of my ToPas project, that converted C code into 
Pascal, at source code level. Adding FPC, as an full fledged compiler, 
will simply eliminate the need for such a code transformation, with all 
known restrictions, and instead will perform the conversion in an lower 
level, at its intermediate (compiler internal) representation.

DoDi