Hi William, Cleaning up is not such a linear process as one would wish. Changes often have unexpected effects so I run the regression set - our library files where each of us has used other enhanced JAL constructs - quite often. Probably is splitting parser lines into smaller parts the way to go (and at least, it is the one I am on now ;).
> I like the idea that the grammar is self-documenting. Adding the '^' > for the trees is bit distracting but I understand why it is > necessary. I agree it is distracting to mix the matching rules with formatting ones and more is probably requires to suppress unwanted nodes from the tree (like parenthesis). It is also possible to split this with '->' and then repeat the elements you want. This might be better to read for shorter rules. I'll give it a try. > Likewise the L_names aren't so bad either. I was a bit > shocked at first, but you chose a nice naming convention so really it > is fine. Shocked? That bad? To keep overview, I needed an easy way to see the difference between a litteral token I completed and more complex and untouched ones. I might change it back later, but that kind of refactoring is quickly done. Note that each token name also is a define in the target C program, used to recognise nodes. So it might be usefull there to have a naming convention of antlr tokens. Joep -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
