I'm not at all familiar with the inner workings of Falcon, but I know that FalconJX relies heavily on the current Falcon AST. Will the new AST be compatible with the old (that may be a silly question, but it's the only one I know to ask)?
EdB On Wed, Jul 23, 2014 at 2:36 PM, Christofer Dutz <christofer.d...@c-ware.de> wrote: > Ok ... so I used some idle time setting up a clean falcon-antlr4 module > starting with the CSS parsing. > > As far as I can see it, Falcon is currently using Antlr3 to generate the > lexer and a parser that generates an Antlr AST from that > Then we generate a second parser CSSTree.g to convert that AST into the > falcon-internal object structure, which is then > passed to JBurg to generate the output. > > As you mentioned the ability to manipulate the AST. Are you talking about > the first (antlr) AST or the one the Falcon AST? > I would like to elminiate the second parsing step and generate the > internal model directly from the first parser using > Antlr4s Listeners. Are there any objections against this? I doubt that > anyone is manipulating the Antlr AST directly, much > more would I expect operations to be performed on the Falcon AST. > > I managed to get the CSS Lexer and Parser finished. The grammar is way > more readable now and the general structure is > much more straight forward :-) Now I would like to Build the internal > Falcon object model for that. > Guess I would have to contact the JBurg guys for continuing from then as I > definitely need Antlr4 support but I would > bet that either JBurg is dead or they are working or at least thinking > about that. > > I did detect some ugly cyclic dependencies in the falcon classes though > ... for example we have interfaces for defining the > internal models interface and have implementations of these interfaces in > the internal packages, but unfortunately the > interfaces reference classes in the internal model ... I think that's bad > design and would like to clean that up. > > Any objections? (Keep in mind ... it's all in a dedicated branch, but I > don't want to make it hard to merge back as soon as I'm finished) > > There is no DOM or SAX involved in Falcon ... I was using a metaphor to > explain what I was thinking about by using > an example from the XML processing world. Here you can load an XML > document to memory (DOM), transform that into > a second memory representation and so on in contrast to SAX processing > where parser generates a stream of events which > can be processed allowing you to process petabyte big documents with as > much ram as a calculator ;-) > > > Chris > > > ________________________________________ > Von: Alex Harui <aha...@adobe.com> > Gesendet: Mittwoch, 23. Juli 2014 08:48 > An: dev@flex.apache.org > Betreff: Re: AW: AW: AW: Falcon and Antlr4 > > On 7/22/14 12:07 PM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote: > > >The way I understood JBurg is that it seems to have been designed to > >manipulate ASTs produced by Antlr2 and Antlr3. > >Therefore it has a compile and runtime dependency to Antlr (I also sort > >of dislike them bundling the generator together with the runtime stuff) > >but nevertheless ... I can't really use JBurg with Antlr4 in my project > >not without splitting the module up but I think that's rather ugly. > I'm definitely not an expert on the subject. I'm surprised the AST has > any Antlr-isms in it. Maybe Gordon can confirm. When I look at the AST, > I don't see anything I find surprising. > > > > >I too was thinking about making JBurg obsolete too ... the way I > >understand Antlr4 it looked as if it provided a lot which could make life > >a lot easier. For example currently the ASParser creates the AST objects > >and JBurg then performs it's magic on that AST tree. In Antlr4 I could > >create a Parser-Listener that produces the AST object (Probably needed > >for IDE suppoer) but could probably create a second listener that > >directly outputs flash bytecode. I think this approach should be maximum > >performant, maximum simple and use only a fragment of the memory the > >current solutions need ... Sort of XML Dom processing (old AST parsing) > >and SAX (Antlr4 direct Bytecode output). > I have not played with SAX much nor Antlr, so I have no idea about > parser/listener. I will say that there are times folks want to create the > AST and then manipulate it before generating the output, so unless there > is a huge performance win, making sure there is a way to do that would be > preferred. > > > > >But I also think that this would be quite an effort. Perhaps I should > >split up my falcon-antlr4 branch even more and sort of start with the CSS > >parser and as soon as that's up and running get the output running ... > >then we could compare the performance of both and see if it's worth going > >down that path. Don't want to waste time I could be working on Flexmojos, > >or the new Flex-Maven-Plugin for a less performant solution. But if it > >was faster (I would expect it to be) it could be quite breakthough ... > >after all I have never seen several datastructure conversions be faster > >than direct output. > Up to you since you are doing the work. I just want to make sure you > don't feel like you have to keep all of these subsystems like Jburg and > Jflex around. > > -Alex > > -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
