[fpc-devel] Alternative parsers

[Juha Manninen (gmail)]

On Tuesday 19 October 2010 14:44:38 Florian Klaempfl wrote:
> Am 19.10.2010 11:08, schrieb Juha Manninen (gmail):
> > First Pascal-like languages and later C.
> > FPC's main developer doesn't see a need for it.
> 
> Indeed. Please tell what a C front end to FPC helps? FPC has no
> advantage over existing C compilers except being a pascal compiler ;).
> Do you think any C developer will work on a C compiler written in
> pascal? It won't make interfacing C headers easier as explained multiple
> times. So what do you expect from a C front end?

C may be difficult but there could be more pascal-like languages like Modula and 
ADA. My idea is that they can use the same libraries and can work together 
even inside one project. I don't know how far the compiler modes in FPC can 
take you for supporting other languages.

It would be a similar concept that .NET and Java VM's are for typed, garbage 
collected languages and Parrot is for dynamic languages. Every language under 
those VMs can call the same libraries. The FPC supported languages would do 
the same (use common libs and variables defined in those libs).
IIRC there is no such thing now for compiled languages. GCC supports many 
languages but they can't interact transparently. Some clumsy glue code is 
needed for that.

C language support for FPC frontend would be possible but compiled (binary) C 
libraries could not be used and existing C source not used directly. Difference 
in default calling convention is solvable I guess. Anyway I don't see this as 
a very important feature neither.

Multi-language support was mentioned earlier in DoDi's mails as part of the 
plan, after refactoring. That's why I wrote about it.
The fact still is that his plan is fundamentally different from your plan.

I don't really have an opinion about if DoDi's patches are good or bad. Maybe 
you did the right thing by not letting such big changes into FPC trunk.
However, I am curious to see what he can achieve. He clearly likes to 
experiment and refactor a lot, and a fork is the only way to do that.

The options are about like:

1. He will send some more mails and big refactoring patches which are again 
rejected, probably for good reason. After lots of frustration he gives up and 
the energy is vasted. Nobody is happy.

2. He will freely modify and refactor the code in a separate branch or fork. 
When there is a stable compiler available, features are compared and a healthy 
competition is born (hopefully). Everybody is happy.

I am just saying that from those options I prefer to see number 2.


Regards,
Juha