[Lazarus] Using FPC parser/tokenizer for code formatting

Hans-Peter Diettrich DrDiettrich1 at aol.com
Sat May 29 06:35:34 CEST 2010


Florian Klaempfl schrieb:
>> Would I have your blessing if I proposed a bounty to unentwine them so
>> that each one of those major modules becomes objects in tehir own right
>> --commnicating with one another through public/published events and
>> properties.
> 
> 15 years ago I had similiar dreams. Within the last 15 years I learned
> that a compiler is something different: one does a clear design and then
> a border case pops up (followed by more) which kills this design.

I had similar problems with my general decompiler, in writing front-ends 
for various binary and textual formats. But with a restricted goal, 
covering Pascal-style languages in the first step, I think that a 
separation is feasable. Even a C frontend should be feasable, as I've 
demonstrated in ToPas, and Borland in CBuilder/Kylix; this would be 
interesting with regards to iPhone etc., where Apple requires 
applications written in (Objective) C.


> I
> wrote a lot of other software during this time but nothing is comparable
> in this regard with a compiler. I'am pretty sure not only FPC has this
> problem, gcc has it as well (just look at the sources) and considering
> the trouble Borland, CG etc. have to create a 64 bit delphi compiler
> hints that they might have the same problem.

A 64 bit compiler deserves a different back-end, and eventually 
appropriate intermediate objects (for storing 64 bit pointers). This is 
what FPC has since a long time, while the Delphi compiler was targetted 
at x86 for Win32 only.


> So I simply don't think
> that this can be achieved in a reasonable time. IMO the effort to do so
> should be spent in existing pascal parsers.

Just the number of existing Pascal parsers suggests to me that time is 
spent *better* in a front-end unification, than in maintaining and 
synchronizing any number of independent parsers.

DoDi





More information about the Lazarus mailing list