Frank Heckenbach wrote:
However, if you want your compiler front end to be written in Pascal, I would recommend against bison. The most natural way to write a Pascal compiler would be to write an RD parser by hand. RD parsers have the advantage that it is possible to understand what they do by reading the source code. For each rule in the grammar there is a corresponding Pascal function/procedure. Table driven parsers have their logic in data tables and therefore it is very difficult to figure out what is happening by reading the code, you really need a debugger to get an understanding.
Maybe you misunderstand how parser generators are used.
Most certainly not. I have used and tried just about every free tool there is.
read and debug the generated tables. Instead you read and write the grammar rules whose syntax is similar to BNF, i.e. what you find in standard documents and such. To debug problems in your grammar, you look e.g. at Bison's verbose output. To debug problems when Bison mis-translates your rules -- well, I've yet to encounter that ...
The reality is that you have used this tool for 10 years or longer and the base from which to possibly recruit one or more new maintainers is unlikely to have this experience. The learning curve is far steeper with table driven parser generators. Just hang out for a few days in the IRC support channels #parsers and #compilers and you will see how confused both newbies and not-so-newbie-anymores are when they use yacc/bison.
Moreover, in recent years the trend has been to move away from yacc/bison and move towards RD and PEG. There is an entire generation of newer tools that build RD parsers, both conventional and memoising, such as ANTLR for example.
This all means it will be more difficult to find new recruits if you use bison. It's as simple as that.
I've given reasons and examples why I'm convinced a manually written parser is not a good idea. You ignored them. Now, I don't want to sound smart-assed, but I'm actually talking from a few years of experience.
So do I.
Of course, you're allowed to repeat others' mistakes if you prefer.
You have the wrong idea about the process of writing an RD parser.
People who write RD parsers by hand generally calculate FIRST and FOLLOW sets and proof that their grammar contains no ambiguities. It seems you have run into somebody who didn't do that but that doesn't mean that this is how its done.
Some do their proofs by hand, some write a tool to do the proof using the grammar as input and some use an existing tool. Just because you write your parser by hand doesn't mean you have to do the proof by hand.
Whichever way you do it, your grammars are verified and unambiguous when you start coding your parser.
And the available (free) tools for designing and verifying grammars for RD and PEG parsers are far more suitable for newbies. Take the IDE for ANTLR as an example. It's called ANTLRworks and it generates syntax diagrams on the fly as you type in your grammar rules and when you tell it to verify the grammar it shows any conflicts and ambiguities graphically within the generated diagrams. This is an excellent teaching tool for a newbie that reduces the learning curve by an order of magnitude.
Also, the new generation of tools such as ANTLR are increasingly used in university course work. Again, a recruiting advantage for RD/BEG.
Also, there are better parser generators than bison even without the graphical editing. COCO/R for example. Originally developed by Moessenboeck (co-author of Oberon-2) in Modula-2, it has since been ported to Pascal by Pat Terry and it generates RD parsers written in Pascal. It's open source, too.
Oh look, another subset compiler ...
Yes, indeed a subset compiler for the purpose of illustrating the text in the book. It is well written and it explains most if not all the important concepts and techniques you would encounter when writing a Pascal compiler.
Or would you rather recommend the Dragon book to a potential new contributor who says that compiler construction is new to them? I doubt that will increase your recruiting chances.
I am beginning to sense that you are right about your prospects finding new recruits amongst the generation of software engineers who are now at university or have just graduated. It would seem indeed more difficult with the kinds of choices you seem to want to impose.
Anyway, good luck.