Fabien COELHO <[EMAIL PROTECTED]> writes:
(b) write a new "recursive descendant" parser, and drop "gram.y"
er, that's "recursive descent" :-)
Been there, done that, not impressed with the idea. There's a reason
why people invented parser generators...
Well, unless you are a serious masochist, cutting a parser of the LR family (including LALR(1), such as yacc/bison produce) by hand is very difficult and error prone. That is not the case with LL type parsers. Also, there are parser generators for this family, both table driven and recursive descent. The table driven variety especially can have quite well tuned error reporting and recovery. (Among the reasons I know this is that I actually wrote such a beast around 13 years ago).
That is not to say that I think we should move from the present setup. Familiarity of the developer community with the tool used suggests we should not, quite apart from any other reasons. Changing to, say, an RD parser, would be a massive and probably error prone change and the benefit just doesn't seem worth it.
In fact, considering this thread I'm not sure any of the suggested steps will achieve Fabien's goal. ISTM that a smarter "training wheels" frontend, perhaps with some modest backend improvements, is likely to have better results. ("Oh, you found an error near there - now what do I suggest belongs there?")
cheers
andrew
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
