On 6 September 2010 16:33, Per Bothner <[email protected]> wrote: [snip] > As an old curmudgeon, I still prefer a hard-written recursive-descent > parser. It's simple, efficient, and much easier to debug. You can set > a breakpoint in the parser and inspect the parser state. You don't have > IDEs getting confused. Yes, some parser-generators have debugging tools > and IDE interfaces, but that's more stuff you need to install and > understand. > > (For typical arithmetic with infix operators, one uses an operator > precedence sub-parser.) > > Error recovery is a mixed issue: It is easier and more flexible to add > recovery in a hand-written parser, but this is where a generator could pay > off - but note that (for example) learning how to use ANTLR's error > recovery features is another learning hump. > > More appealing seems to be a parser library (or language feature), as in > Perl 6 or Scala, but I don't experience with those.
I must agree; certainly if you're designing a language and fiddling with the syntax. If you're implementing an existing language then you will presumably have the BNF so a parser generator makes sense. Groovy is a good example of this. It took us ages to get the small details of the syntax right (especially the optional semicolon stuff). An ANTLR grammer would actually have made it harder (unless we'd has a world class ANTLR wrangler, which we didin't). We ended up with a hand crafted parser which had numerous idiosyncrasies but got the basics right. Then it was possible to produce a grammer which removed the numerous parsing bugs but kept the important characteristics of the syntax of the language. If you start with BNF you end up with a syntax which is easy to define and hence easy to parse. What you really want is a syntax that it's easy for humans to read and write - the two are not normally compatible. I think error recovery is less important than it was in the days when we had one or two batch runs per day. Error location identification is more important. With virtually instant compilation I can live with a compiler that doesn't find all the errors in one parse. John Wilson -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
