Quoting Frank Wienberg <fr...@jangaroo.net>:
Totally agreed, Mike! We're facing a great opportunity, but also a big challenge. Adobe's code is, especially considering the lack of a language specification, the best you can get to parse ActionScript 3.
I have written an AS3.g (1600 lines) file with a rewrite tree, I know how bad the language is. BTW, Falcon uses an antlr grammar for the parser, did you know that?
However, when
we (especially Andreas Gawecki, the original author of the Jangaroo compiler) looked at the Flex compiler code, we found it quite complex and wondered why no grammer / parser generator had been used. It all seems hand-coded. So we decided to stick with our compiler, at least for a while. Also, we did not want to emulate SWF / SWC, but rely on generated JS code + AS3 API stubs. All relevant tools can handle that very well: we use ASDoc and IntelliJ IDEA's ActionScript support successfully. We only had to create Jangaroo-specific build-tool support, namely a Maven plugin. So both compilers have their advantages, and we would like to unite them, but that seems like a long way to go.
I don't think so. The Falcon compiler has a two APIs, ast nodes(low level) and definition nodes(high level). It is a very robust design.
Can somebody explain why it is not easy or even not possible to use Falcon to create the AST and refactor the Jangaroo JSCodeGenerator from the Jangaroo-AST to the Falcon-AST to produce the JS output? I don't really get the SWF/JBurg part...
I think as far as AST we could do anything, I love the Falcon compiler. I think the way JS is created AFTER the compile sucks.
I bet if I had some time I could port some of your generation code using the Falcon AST.
Maybe there is a translation thing happening here, I didn't say that it's not easy to create falcon AST, I said the processing step AFTER AST creation is convoluted in my opinion. It's not accessible to the average higher level dev.
JBurg is used to create a reducer and emitter for js source code.
One thing that's good in FalconJS and missing in Jangaroo is to produce output that Google Closure Compiler can optimize well. I think it should not be too hard, but it seems to conflict with Jangaroo's goal to keep the output format as close as possible to the AS source code, and of course it has to be done.
I can't comment on this since I'm not to versed in JS. Mike
-Frank-
-- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com
