Hi,

Speaking of language syntax in another thread it got me thinking. Being around FPC for a few years now I have read many messages and saw patches regarding language extensions etc...

Then today by pure accident while searching for Modula-2 if..then..end syntax I came across this page:

http://www.scifac.ru.ac.za/coco/

Coco/R ( a compiler generator). A language syntax is described in a rather simple manner. You then feed this information into a program and it generates a parser and scanner. The above URL mentions versions available for Modula-2, Pascal, Delphi and many more...

Students from the Rhodes University used Coco/R to create a new teaching language based on Modula-2. They called in Umbriel, and used Coco/R.

http://scifac.ru.ac.za/cspt/sigplan.htm

I gather FPC doesn't use something like this? If so, any specific reason why not? It seems like a very easy way to extend the language though. Simply describe the syntax and another program generates the code.

Here is more information on Wikipedia about Coco/R http://en.wikipedia.org/wiki/Coco/R

Mainly because it's very inefficient, has little useful error reporting and requires yet another tool.

Also, when the compiler was created, Coco/R didn't exist yet.

and I'm sure Florian can think of some more arguments :-)

Michael.

I don't know how the situation is currently, but at the time basic FPC was written, compiler generators generated slow code (and wasted memory), error recovery was hard, one dependend on an external tool with all it disadvantages, running the compiler generator was an extra step (remember, I did the initial development of FPC on a 386-40 with 4 MB memory on DOS), debugging a yacc generated parser being table driven is a pain etc.

Today this might have changed but considering that gcc uses now a handcoded frontend as well, I don't believe in this.

It seems like a very easy way to extend the language though.

Extending the language is usually simple, maintaining it is really hard. Just look at the generics, we're still fighting with its pitfalls.

Coco/R is good tool, we used it on University at Compiler Construction course (Modula2 was our official language), but it is nowhere powerful enough for FPC's needs (just think of syntax modes). It's easier to learn about scanners/parsers/tokens and implement it manually than to use Coco/R. Plus, you get better understanding of [part of] compiler internals.

Regards,
Aleksa

2010/1/26 Michael Van Canneyt :

Fair enough. I guess one could use Coco/R or other similar tools to generate parsers for other things too, like LaTeX for one. I worked on a table based parser for LaTeX, but my desired IPF output was not exactly what I wanted, so I put the project on hold for now. Maybe something like Coco/R could get me going on that project again.

and I'm sure Florian can think of some more arguments :-)

I'm sure he can, I was just curious though.

2010/1/26 Florian Klaempfl :

(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.

No idea what all this means though, but I'll read more to try and find out. :)

2010/1/26 Florian Klaempfl : > (remember, I did the initial development of FPC on a 386-40 with 4 MB Wow, that must be long ago.

The "current" FPC code base was started in June 1993. Nice task for the git addicted to take available old sources and cvs repositories and stich together a git repository with a rather complete history ;)

This might be, but reasonable error recovery is usally much harder.

In our previous episode, Graeme Geldenhuys said:

(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.