[fpc-devel] Coco/R usage for FPC

[Marco van de Voort]

In our previous episode, Graeme Geldenhuys said:
> > (remember, I did the initial development of FPC on a 386-40 with 4 MB
> 
> Wow, that must be long ago.
> 
> 
> > memory on DOS), debugging a yacc generated parser being table driven is
> > a pain etc.
> 
> Not that I understand anything of this or compiler internals, I have
> read that yacc is table driven, and such tools are normally better at
> error reporting. Coco/R uses recursive descent <something or other>
> which is apparently better at performance and speed output.

(hmm, I thought RD was better at errorgeneration, at least with the same
amount of effort invested)
 
I discussed about this subject with a professional compilerbuilder (in
embedded circles). They used a commercial compiler construction tool, and I
asked why, and what the tradeoffs had been.

His answer was that they mostly retargeted compilers to a new embedded
target, with some target specific extensions (like register access etc), and
could reduce the impact of these changes due to formal validation methods of
the grammar. (and other grammar analysis tools), making them deliver more on
time.

Keep in mind that in order for this to be useful, the tool must be more or
less stay validated, and thus can't be constantly modified (because then the
validation becomes uncertain too), so you have to live with certain
limitations. (which they usually worked around in code for the rather
limited changes)

Now look at FPC, and see how much new syntax arrives with a major version
(in trunk: d2006 extensions like for..in, classvars, fpc new syntax like
case of string, little modifiers are often added, generics etc, delphi
compat fixes). And then I'm not even talking about complete new modes like
objective Pascal, Delphi, Macpascal, TP obj syntax etc was added. (was tp
obj syntax in from the beginning? FPK?)

I think the main reason why gcc stayed so long with flex/yacc is more that
it is Unix tradition.