[fpc-other] What makes a Compiler project (like FPC) special?

[noreply at z505.com]

On 2017-05-25 16:21, Nikolay Nikolov wrote:
> On 05/26/2017 12:16 AM, Graeme Geldenhuys wrote:
>> On 2017-05-25 22:04, Marco van de Voort wrote:
>>> There are no narrow interfaces that are natural seams for
>>> modularization inside the compiler.
>> 
>> Yet the “packages” and “rtl” directories is just that - which by the 
>> way is part of the FPC project.
> "packages" - yes. But "rtl" is a lot more tightly coupled to the
> "compiler" than you think.
> 

Indeed, all the string routines and reference counting is tied to the 
compiler.
I learned this when I had an idea for a new string type..

A string(1000) instead of string(255) or a string(arbitrary). Fixed 
length string that can go beyond 255. Oberon has it. When you introduce 
a new type into the RTL that is not a class, but a type that is part of 
the language itself you have to add all the routines in sysutils to deal 
with this type, change the compiler, make overloaded string routines.

And system.pp is tightly intertwined with the compiler and is almost a 
run time for the language. Not as much like Plain C, but probably even 
Plain C has some connections to the include files and the compiler

Then there is writeln too which is tied to the compiler as it is like a 
varargs, but accepts multiple types. So if you introduce a new 
string(1000) into the compiler, writeln also has to be modified to 
accept this new type as a parameter. But not just writeln, other things 
too.

If you don't have this intertwined and tightly integrated system you 
just end up putting things into a Lisp like system where it is all 
defined by not the compiler/rtl, but the libraries/modules which changes 
the language at run time. Powerful but also double edged sword that 
makes the language redefinable - open for abuse and misuse, such as 
lisp's ability to basically rechange the entire language to any thing 
you want as long as you include (some(brackets)) but everything else is 
up for grabs.