Really, Token should implement Node, shouldn't it?

[Jonathan Revusky]

One striking thing about JavaCC/JJTree is the extent to which JJTree was
kind of written as an afterthought and grafted onto the existing system.
Really, the whole scheme of having a separate .jjt that generates a .jj
that then generates a .java file is quite convoluted.

Anyway, it really seems to me that, at least if tree-building is
enabled, Token should implement the Node interface. After all, a Token
is really the lowest-level Node basically, the atomic node if you will.
Of course, storing the Tokens in the AST could be made optional.

Also, I think that in KawaDD, direct use of the public fields beginLine,
endLine, etcetera, should be deprecated in favor of getters and setters
that are (will be) in the basic Node interface (that Token then
implements) and then there is a conceptual unity to Tokens and Nodes.

AFAICS, Tokens are really just terminal nodes, right? At least when you
are looking at things from a tree-building/tree-walking POV. In fact,
people might be encouraged simply to access Tokens via the Node API --
at least when writing typical tree-walking code. Then there might be a
lot of flexibility about refactoring a grammar so that stuff that was a
production before is now a Token or vice versa, and the basic
tree-walking type code would require very little change.

Anyway, generally speaking, the above kind of stuff I'm thinking out
loud of course, but note that with the code cleaned up the way it is,
these kinds of things are really very low-hanging fruit. So, if we have
a discussion and figure out how we want things to be, it can be made so
very easily. :-)

JR