hi. I'll tried to avoid modifying the tree and just bail out when necessary. I like leaving the tree unmolested so people can use it in development environments as the representation of the input. When I need to automatically insert syntactic predicates in backtracking, I will make a complete copy of the input tree and make changes to that.
I have a list of errors that prevent passing on to the next phase in v3, I guess I can move those into the ErrorSeverity; I think you have something set up there now. This version is going to be much much cleaner. I now know exactly the kinds of things that go into the software and so now I'm organizing with complete information as opposed to learning as I go. standard stuff. Ter On Feb 1, 2010, at 1:33 PM, Jim Idle wrote: > There are too many variables so I say that you barf on parsing and do not > even go on to tree walking, then you stop after walking the tree and issue > all the errors you can. So only move into the next phase if the current phase > was clean. I usually have two internal error levels, being error and fatal. > Warnings mean carry on, error means you can carray on, fatal means abort and > do not do next phase. Users only see error and not the error/fatal > distinction. Most errors end up being fatal, but this way if there are one or > tow that it is feasible to carry on from, you can flag as such :-) _______________________________________________ antlr-dev mailing list [email protected] http://www.antlr.org/mailman/listinfo/antlr-dev
