Objective Modula-2 wrote:
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.
So why do claim you need a debugger for understanding? In all my Bison use, I've never needed one, and it would be among the last tools I'd think of. You don't use a debugger when you've confused about you class hierarchy in OOP either, do you? (In both cases, it's just several levels too low.)
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.
Except, as I wrote initially, the grammar is exactly one of those areas where we wouldn't need to spend much work, because it exists and works already. Even if the semantic actions have to be rewritten, and even in the Bison parser code has to be translated to Pascal at some point, the grammar rules and their logic are not affected.
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.
Sorry, I don't have a few days to spend on this argument.
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.
How powerful are they? GPC with its mix of dialects needs even more than LALR(1), i.e. Bison's GLR 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.
Borland apparently didn't prove their grammars (because their grammar did contain ambiguities).
To the FPC people who are reading this, how do you verify your grammar?
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.
I still don't quite see the point. With RD, you specify the grammar in a formal way and write the parser manually, and it's verified automatically. With Bison you specify the grammar formally, and the parser is generated and verified automatically. The former seems more work to me.
And the available (free) tools for designing and verifying grammars for RD and PEG parsers are far more suitable for newbies. [...] 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.
Sorry, GPC grammar is *not* something for newbies. Even if I sound condescending, but the GPC grammar is about the last thing I'd recommend to someone new to compiler construction.
Also, the new generation of tools such as ANTLR are increasingly used in university course work. Again, a recruiting advantage for RD/BEG.
I've only read about PEGs, but it seems to me, they "resolve" ambiguities and (non-ambiguities) simply by shifting this burder on the grammar developer who has to specify the correct order of alternatives.
Indeed, the Wikipedia page says:
: In order to express a grammar as a PEG, the grammar author must : convert all instances of nondeterministic choice into prioritized : choice. Unfortunately, this process is error prone, and often : results in grammars which mis-parse certain inputs.
The nice thing about Bison is that I can just throw some rules at it (e.g. mixed from different dialects), and it tells me whether there are any conflict. With PEG, I would have do choose an ordering by myself, there wouldn't be conflicts (by definition), but I could never be sure whether the parser actually parsed all I intended.
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.
Yes, my preference is not rewriting what's not broken (e.g., the grammar) for the sake of it, nor implementing a compiler for a subset language (even if it's a very clean subset) that may or may not grow in 10 years to something more or less similar to GPC, but something that can actually compile my existing (not hypothetical) programs, and thus would need to be (mostly) backward-compatible with the existing GPC.
Frank