[Lazarus] Parser

[Hans-Peter Diettrich]

Michael Van Canneyt schrieb:

> You are missing the point. The point is not DOING it. the point is the
> support afterwards. After 15 years of FPC support, I have some experience.
> Even now, bugs creep up that are seemingly SO basic:
> W : word;
> begin
>   w:=0;
>   for i:=0 to pred(w) do // What to do ?
> end;
> 
> The compiler's behaviour is different from Delphi. This is a bug, we must
> deal with it. After 15 years. So, if the compiler produces different code
> in some C library, then we'll have to deal with it. People will report it.
> So no, thank you.

Thanks for the concrete example. I also remember a discussion about 
Inc/Dec, where every improvment (taking into account the signedness of 
the operand) was rejected, in favor of the "translate into a single 
machine instruction" - where not every CPU supports such an instruction.

With regards to subtle OPL/C differences I don't expect that these are 
handled by the FPC team. Additional front-ends are not a concrete 
subject right now, they only came up as another chance to extend the 
compiler. Furthermore the C language specification is quite vague in 
many details, while an OPL specification does not exist at all, so that 
code like the above most probably will behave differently, depending on 
the used compiler (both as C and Pascal code).


> And frankly, I would not use topas as a reference. I tried it on some - to
> my taste - simple C code and it failed horribly. I was unable to solve 
> it, also because it lacks all documentation. This is not the kind of 
> standard I would like to see in FPC.

Do you seriously expect that things will change, without any feedback? :-(

Perhaps you missed the ToPas documentation, available in a separate 
download? I know that this project is very hard to use, due to the 
dependency on external resources (header files, compiler 
specifications), so that I can understand when people have problems to 
use it as-is. That's why I abandoned further work on this project, many 
years ago, after I could make it work with the header files and 
libraries of several compilers. And there was no reason to put my hands 
on it at any later time, due to zero feedback. In detail I missed 
feedback with ideas to make it easier usable.

> So I'd say that you already failed on something more simple than FPC
> compiling all languages. First get topas to convert all C code out there 
> without a glitch, then we'll talk again.

The base of the ToPas project was the C preprocessor and parser, 
previously implemented as the CScan project. ToPas effectively is a test 
application for that project, and there I found no way to make it an 
*easily* usable tool. In so far an FPC front-end would be just another 
test case for CScan, where it could be made usable much easier, and 
possibly with more helpful feedback.

> Do not get me wrong: I think topas is a technically nice product. I admire
> that you can write the code to do it, to make it work (more or less). 
> That is
> not the point; The point is that writing the code is actually the least of
> the problems. It's what comes afterwards.

I'm still waiting for such problems, and I'm willing to fix all known 
bugs myself :-)



> Because Microsoft has 1500 people, GCC has several companies behind it.
> FPC has 4 people technically savvy in compiler matters.

So the addition of only one person (me) would add 25% percent to the 
staff - which other compiler manufacturer can afford such an increase? ;-)


>> I wonder how somebody can say "it's hard to do", without having even 
>> tried ;-)
> 
> I didn't say it is hard. I say that the support for it would kill us and 
> the
> project.

That's why I intend to make the (eventual) C front-end a non-breaking 
add-on to FPC, that relies on nothing but the existing compiler 
infrastructure and back-ends. Then we can find out more about the hidden 
capabilities of the compiler, and the chance and problems of integrating 
(very) different languages. In case that project fails to work 
sufficiently, due to unforeseen language incompatibilities, I've spent 
some time at least with learning more about concrete compilers :-)


> This is the problem of most open source out there:  Enthousiasts write
> it. And then the good is separated from the bad: supporting it for many 
> years. Patiently fixing all bugs. And there will be lots.

I've already been spending much time in the Lazarus docking managers, so 
that now the IDE offers docking support, after years of preparations. 
But since this project is almost finished now, I'm looking for further 
projects, that may be useful to others. I can spend all my time in such 
projects, the only limitation is increasing age and consequential health 
problems.

> FPC existed before the term 'Open Source' existed.  That means something.

My discompilers (borrow'd from "disassemblers") also worked a long time 
before the term "decompiler" was even born ;-)

I only didn't publish them, except for the VB3 decompiler, because I 
wanted to control their use myself. Many hundred pleased customers made 
me continue the evolution of this project, over a couple of years. Even 
in the last year I've supported two new customers, but now VB3 seems to 
be really dead, with all VB3 applications either being decompiled or 
upgraded to newer VB versions.

DoDi