Re: [gcjx] Patch: FYI: parser and lexer changes

[Tom Tromey <tromey at redhat dot com>]

Per> Also, Jikes only generates bytecode.  We generate native code as well,
Per> which means more general-purpose and probably less efficient trees.

In this case the comparison is reasonably appropriate; gcjx doesn't
yet implement all of 1.5, and I was only comparing the bytecode
compiler (which doesn't use trees at all).

Per> If Jikes's parser really is a lot faster, it may be worthwhile
Per> reading its code to see what they do.

They use a parser generator called "jikespg:.

Per> In any case, if we only need peek and peek1, do we really need a
Per> a deque for the tokens?

Per> I see that you have a mechanism for "mark" and "backtrack", and it's
Per> used heavily - i.e. for parse::primary.  Is that really needed?

The answer is "no" to both of these.  Maybe we can salvage the current
code without going to a generated parser.  I'm putting this off again
for a while :-)

Per> You might find some ideas in the XQuery parser:

Thanks, I'll definitely look.

Tom