I started writing a JFlex lexer spec by hand, and realized it would be
much simpler and more maintainable to generate the lexer spec I desire
from another sort of meta-spec.
Basically, I want to describe the second and third sections of the
lexer spec (options, macros, and lexical rules) in XML -- with the
additional feature that regexp definitions will have names.
Then I'll write a program that takes this XML and generates several things:
- an enum containing the names of all the states
- enums containing the names of all the regexps in each state
- listener interfaces for each state, with methods corresponding to
the names of the regexps.
- also a state change listener interface
- a JFlex lexer spec with:
- addXxxListener(XxxListener) methods for each type of listener
- actions that call the listener methods associated with their regexps
The advantage of all this is that no application code would be
embedded in the actions of the lexer spec. All the application code
would be in the class(es) that implement the listener interfaces.
This would make the action code much easier to write, debug, and
refactor than if it were in the lexer spec.
I can think of a few kinks that will need to be worked out, like how
to handle regexps that are to be matched in more than one state. I
suppose I could make it an option to generate a single enum with all
the regexp names, or separate enums for each state.
My only question before I do this... am I reinventing anyone's wheel?
|