[fpc-devel] Proof of Concept ARC implementation

Marco van de Voort marcov at stack.nl
Mon Oct 27 22:23:07 CET 2014


In our previous episode, Boian Mitov said:
> Well... since attributes can be implemented in compiler extending library, 

And tell me again why directives couldn't? A switch or whatever trigger could
also plug additional directives into the parser. (and then I'm not even
discussing the actual use of plugging).

As said the only *difference* is to skip and ignore unknown attributes since
they are a defined list. But then one must have the actual luxury of
skipping them and the program still working.

And e.g. in the case refcounts skipping that will leave some pretty big
memory leaks :_)

> I think library extension of the compiler is a better option that having a 
> bunch of switch directives.

You made that clear. I just don't understand really why. The extra
interfaces only make the result harder to control. A pluggable program is
much harder to maintain than the same functionality monolithically.

> This also allows users easily to customize the compiler for their needs.

That's the only reason to do so. But that is for third party uses, usually
for one application or framework or platform dependent. Not for core
language features that hit both code generation and library.

> Now I know the concept for compiler being expanded/modified via library is 
> probably a new one, but .NET already has introduced elements of this years 
> ago, and seems to work well for them ;-) .

.NET afaik mostly uses it to give hints to the fringes of the system, like the ASP.NET 
containerized instances of the .NET framework for safety and load balancing
etc, and to interop to communicate to the outside of its walled garden.

There was life in languages before .NET, don't worry ;-) Trying to make
pluggable languages is almost as old as the road to Rome.
 



More information about the fpc-devel mailing list