Tom Lane wrote:
>Fabien COELHO <coelho@cri.ensmp.fr> 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
