[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