The falcon ast. I wasn't aware there was another one. Can we skip the first one? Sent via the PANTECH Discover, an AT&T 4G LTE smartphone.
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
