Re: Syntax diagram driven parser

I find the "railroad diagram" form of EBNF easier to read than the
textual form. See the appendix to Paulson's book "ML For the Working
Programmer" for a nice example.


A browser that would allow me to pop between -- or expand -- diagrams
would be even nicer than having the diagrams on the printed page.


As far as editing such diagrams -- sure it's a nice idea. Think
carefully about error reporting: depending on how you have split up
diagrams, shift/reduce and reduce/reduce errors may refer to pairs of
diagrams -- if you allow the user to pick how the diagrams are split.
If you allow the error reporter to control the diagrams, then you can
show with highlighting exactly the extent of the conflict as a
highlighted path in a diagram.


I would really enjoy such error reporting when / if I next work on a
concrete sytax.


Since the railroad diagrams are just another representation of EBNF,
it should not be hard to extract them from a few standard parser
generators, or to write out a template for input to a parser generator.


It is probably not simple to edit parsers in editing existing parser
generators such as yacc which associate some general eaction with each
reduce.


-- Allyn Dimock

Return to the comp.compilers page.
Search the comp.compilers archives again.