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
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus