Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
I need your advice on something. In the search for better parsers, I came upon a YACC variant http://byaccj.sourceforge.net/. This generates parsers in Java (with the added advantage that the generated classes do not require any runtime libraries). So couldn't we use this in combination with perly.y to make the ultimate parser? Is there any catch? Why didn't the EPIC developers think of that?
It could be a good idea... The catch is probably that perly.y makes calls to Perl internal functions, so what's in the grammar might be only the tip of the iceberg. It's well-known that some constructs in Perl require actual code execution (e.g. of BEGIN blocks) to be parsed accurately, and such code execution can only happen in context of a Perl interpreter (or a perfect simulation of it).
The reason why EPIC developers didn't think of that is that
1) The original EPIC developers just picked the easiest solution that was available, which was to tweak some regex rules in a generic syntax coloring plugin (please correct me if you're reading this and I'm wrong),
2) I didn't aim to implement the ultimate parser and didn't go parser shopping beforehand like you are right now. It was more like, "hey, let me try whether I can stitch together something faster and more accurate than 1) quickly", an undertaking motivated by my frustration with the previous parser's poor performance on large source files. I took advantage of my prior moderate familiarity with ANTLR. My prototype turned out satisfactory enough to replace the previous implementation. Today it still seems good enough, while certainly not optimal. You are welcome to try a different route, and if the result is better or at least "more promising" than the present solution, it can be integrated.