Falcon and Antlr4

[Christofer Dutz <ch...@c-ware.de>]

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

Re: Falcon and Antlr4

[Erik de Bruin <er...@ixsoftware.nl>]

I'm available to help out with the 'grunt' work. Writing tests, doing
repetitive stuff etc. I'm not familiar with the inner workings of a real
compiler, though I have done 'some' work on FalconJX. I'm willing to learn
though!

EdB



On Thu, Jul 17, 2014 at 12:14 AM, Christofer Dutz <christofer.dutz@c-ware.de
> wrote:

> 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:gsmithsf@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" <ah...@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" <ch...@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
> >
>



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

AW: AW: Falcon and Antlr4

[Christofer Dutz <ch...@c-ware.de>]

Ok ... so it seems that in order to procede here, I have to get in touch with the JBurg guys.

Currently JBurg is linked against Antlr2 and 3 but is incompatable with Antlr4. So in order to safely use JBurg as code generator, I would have to update JBurg to support Antlr4 :-(

The project doesn't look that complex, but I think I should concentrate on Flexmojos falcon support first :-(

Chris

________________________________________
Von: Christofer Dutz <ch...@c-ware.de>
Gesendet: Dienstag, 22. Juli 2014 10:06
An: dev@flex.apache.org
Betreff: AW: AW: Falcon and Antlr4

Ok ... so I created a "falcon-antlr4" branch (Haven't comitted/pushed that yet so don't look for it yet ;-) ).

I am now trying to setup the compiler modules structure as a native maven project and will try to get everything up and running with Antlr4

One thing I did notice is that the parsers seem to consist of some Antlr grammar files as well as JFlex .lex files. Is it possible that both are actually doing the same thing?
You said in a previous post that JFlex was used to make the Eclipse suppot more responsive, but if it is only used for that I would like to concentrate an an Anltr4 based parser and throwing out the JFlex stuff making Eclipse use the Antlr4 parser instead after finishing the parser itself ... would that be a valid approach?

In recent projects I have had a lot of trouble and strange effects when not using the standard maven directory layout because some third party tools make assumptions that might not apply in non-maven-structures. On the other hand making an Ant buildscript run with a maven directory strucure is as easy as adjusting a few paths. So I would go that path instead. Would that be ok for you?

Currently this would result in the sources being placed in:
src/main/java (Java Sources)
src/main/antlr4 (Antlr Grammar Files)
src/main/resources (Static Resources such as i18n property files, and other static stuff)

After reading the source, the ant build script and a lot of googling at least I think I now know how to approach this task and I think I's absolutely manageable ... really looking forward to this.

Chris


________________________________________
Von: Gordon Smith <gs...@hotmail.com>
Gesendet: Donnerstag, 17. Juli 2014 17:11
An: dev@flex.apache.org
Betreff: Re: AW: Falcon and Antlr4

> why are we mixing up several tools that all seem to be doing similar thing

Falcon's lexer and parser were borrowed from the Flash Builder code base, where they supported various edit-time code intelligence features, but not compilation. I think the Flash Builder team had determined that JFlex could tokenize faster than Antlr 2 could. But I don't know whether that is still the case with Antlr 3 and 4.

- Gordon

Sent from my iPad

> On Jul 16, 2014, at 3:14 PM, "Christofer Dutz" <ch...@c-ware.de> wrote:
>
> 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:gsmithsf@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" <ah...@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" <ch...@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
>>

AW: AW: Falcon and Antlr4

[Christofer Dutz <ch...@c-ware.de>]

Ok ... so I created a "falcon-antlr4" branch (Haven't comitted/pushed that yet so don't look for it yet ;-) ).

I am now trying to setup the compiler modules structure as a native maven project and will try to get everything up and running with Antlr4

One thing I did notice is that the parsers seem to consist of some Antlr grammar files as well as JFlex .lex files. Is it possible that both are actually doing the same thing?
You said in a previous post that JFlex was used to make the Eclipse suppot more responsive, but if it is only used for that I would like to concentrate an an Anltr4 based parser and throwing out the JFlex stuff making Eclipse use the Antlr4 parser instead after finishing the parser itself ... would that be a valid approach?

In recent projects I have had a lot of trouble and strange effects when not using the standard maven directory layout because some third party tools make assumptions that might not apply in non-maven-structures. On the other hand making an Ant buildscript run with a maven directory strucure is as easy as adjusting a few paths. So I would go that path instead. Would that be ok for you?

Currently this would result in the sources being placed in:
src/main/java (Java Sources)
src/main/antlr4 (Antlr Grammar Files)
src/main/resources (Static Resources such as i18n property files, and other static stuff)

After reading the source, the ant build script and a lot of googling at least I think I now know how to approach this task and I think I's absolutely manageable ... really looking forward to this.

Chris


________________________________________
Von: Gordon Smith <gs...@hotmail.com>
Gesendet: Donnerstag, 17. Juli 2014 17:11
An: dev@flex.apache.org
Betreff: Re: AW: Falcon and Antlr4

> why are we mixing up several tools that all seem to be doing similar thing

Falcon's lexer and parser were borrowed from the Flash Builder code base, where they supported various edit-time code intelligence features, but not compilation. I think the Flash Builder team had determined that JFlex could tokenize faster than Antlr 2 could. But I don't know whether that is still the case with Antlr 3 and 4.

- Gordon

Sent from my iPad

> On Jul 16, 2014, at 3:14 PM, "Christofer Dutz" <ch...@c-ware.de> wrote:
>
> 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:gsmithsf@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" <ah...@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" <ch...@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
>>

Re: AW: Falcon and Antlr4

[Gordon Smith <gs...@hotmail.com>]

> why are we mixing up several tools that all seem to be doing similar thing

Falcon's lexer and parser were borrowed from the Flash Builder code base, where they supported various edit-time code intelligence features, but not compilation. I think the Flash Builder team had determined that JFlex could tokenize faster than Antlr 2 could. But I don't know whether that is still the case with Antlr 3 and 4.

- Gordon

Sent from my iPad

> On Jul 16, 2014, at 3:14 PM, "Christofer Dutz" <ch...@c-ware.de> wrote:
> 
> 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:gsmithsf@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" <ah...@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" <ch...@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
>> 

AW: Falcon and Antlr4

[Christofer Dutz <ch...@c-ware.de>]

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:gsmithsf@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" <ah...@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" <ch...@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
> 

Re: Falcon and Antlr4

[Gordon Smith <gs...@hotmail.com>]

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" <ah...@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" <ch...@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
> 

Re: Falcon and Antlr4

[Alex Harui <ah...@adobe.com>]

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" <ch...@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