Ok so that would have been my second question ... why are we mixing up several tools that all seem to be doing similar things :-)
I definitely like to do some cleaning up. But depending on if any or which talks are accepter for the ApacheCon I might have to finish some other things first ;-) Chris PS: Will be offline for a few days ... -----Ursprüngliche Nachricht----- Von: Gordon Smith [mailto:gsmit...@hotmail.com] Gesendet: Mittwoch, 16. Juli 2014 17:19 An: dev@flex.apache.org Betreff: Re: Falcon and Antlr4 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 >
