Good luck. I'm interested in anything that would speed up Falcon.
Please work in a branch.
On 7/16/14 2:44 AM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote:
>Hi,
>
>
>
>while I was havin a first look at the internals of Falcon, I was
>surprized to find a mixture of Antlr2 & Antlr3 grammars for creating the
>parsers.
>
>In a first moment I thought it would be a good idea to migrate the Antlr2
>grammars ASParser.g and MetadataParser.g to Antlr3 but after finding out
>that IntelliJ now has a neat Antlr4 plugin and reading a bit about the
>differences from 2 and 3 to 4 it sounded like a good idea to migrate all
>to Antlr4. To me it looks as if the way things are processed in Antlr4
>would make the grammars a lot easier as well as implementing the rule
>logic. My gut-feeling tells me that an Antlr4 parser should need less
>processing and be quite a bit faster. I did experiment a little on the
>CSS grammar and successfully created an Antlr4 version of that ... so I
>guess it should be possible and it would clean up things quite
>dramatically.
>
>
>
>What I particularly liked, was that Antlr4 automatically generates a
>Listener interface for any rule it finds generating an "enter{ruleneme}"
>and "exit{rulename}" as well as a base-class implementing this interface.
>Now all of the java code we had to enter in the rule-document can now be
>defined in a FalconCssListener class that extends this CSSBaseListener.
>This is where the Java code can be added to handle the rules and we can
>easily debug it (I know you could set breakpoints in the generated code,
>but I allways disliked that).
>
>
>
>What do you think? ... Would it be a good idea to give something like
>that a try? After all ... it's just 3 grammars (CSS, ASParser and
>MetadataParser). But I have to admit that the ASParser grammar looks way
>more complex than the CSS and the MetadataParser grammar.
>
>
>
>Chris
