You might also want to look into eliminating JFlex and have Antlr handle 
tokenization as well.

- Gordon

Sent from my iPad

> On Jul 16, 2014, at 8:06 AM, "Alex Harui" <aha...@adobe.com> wrote:
> 
> 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
> 

Reply via email to