You've got a big chunk of data to parse. Following the advice of ParseUsingGrammars
and AlwaysBuildAParseTree, you've used a parser
generator (for example, AntlrTranslatorGenerator
), built a BNF and gone to town.
What now ? Now that you've got all the information in memory, in a nice form, how do you actually do something with it ?
. Oh my god. Haven't you written enough code already ? Do you really need to implement a lot more code. This investment in infrastructure may be a long term gain, may have helped you UnderstandContext?
and it will EncourageExperimentation
but ... you need to see something running and doing something soon.
In order for an investment in infrastructure to pay off, it needs to be flexible (and efficient). that's why you went to the trouble of defining a
BNF and building a parse tree, right ?
Use visitors to perform tasks. Implement the full DoubleDispatch
from the start (you're going to need it and, at the start, it's no problem
to build it in) and do all your processing via visitors. You'll be amazed at how elegant the resulting code is (and how easy it is to extend).
Compiler experts often don't follow this advice, because they don't
build parse trees. Building parse trees is a bit of overhead, and
the fastest compilers don't.
But unless you are pretty sure you won't need
them, you are better off building parse trees because compilers
based on parse trees are a lot easier to understand (in my opinion).
So, I agree that this pattern is the one you should use by default.
Please clarify how you see DoubleDispatch
working with the visitor. I can imagine at least two implementations.
Personally I feel a better question would be how do you implement the Visitor pattern without
Odd. The VisitorPattern does not require DoubleDispatch. I've never used DoubleDispatch to parse or process data. I've never used DoubleDispatch to parse or interpret code.
Of what value is DoubleDispatch in this context? -- JeffGrigg