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

Reply via email to