Teoti Graphix, LLC

Hi,

Wow a blog post that is not a summary, well yeah it is another summary but it’s about something that I am really excited about. I have in previous posts expressed my enthusiasm about the new compiler that has been designed from the ground up with cross compiling in mind. How can you not get excited about something that was designed to take on the new decade of multiple technologies!

Well, Gordon Smith of Adobe and Falcon team member for 18 months just gave the flex-dev list a huge update for compiler fanatics like myself. In previous emails he did express interest in getting the community some Javadocs showing the API of the Falcon compiler. Well today he gave us nuts about as much information as we needed to really get geared up and maintain respectable patients over the issue of the compilers donation.

Enough of the boring talkative post, let’s get down to the nitty gritty of information he provided.

Falcon from the beginning was designed to support multiple compiling targets in multiple projects in a workspace. This means that the team really went out of their way to develop a code model that was independent of an IDE. This is great news because it means there are probably a lot of use cases that can be had outside of an IDE regarding tools.

Falcon uses multiple threads to compile multiple files at the same time! Yes, a multi-threaded parser/compiler, nice. As he said, the more cores you have, the faster it goes.

Data structures such as the symbol table which stores information about the types(classes, interfaces, functions) and the members they hold are shared across the compiling workspace. This means you have access to the high-level DOM of your parsing/compiling project fed with source files and SWCs I would imagine. This reduces memory.

Other critical data structures are maintained in memory (IE parse tree DOM) are available on a per file basis to support things such as code intelligence in an IDE. This also paves the way for intelligent editing of the parse tree! Yes, this is so cool! Basically the team has created a rock solid Document Object Model for reading and writing ActionScript. Being able to read and write the DOM in memory is going to open up a HUGE opportunity for tooling developers.

Gordon noted that in the current Flash Builder setup, FB creates a parse tree and when the mxmlc compiler is executed, the mxmlc compiler creates an additional parse tree, huge waste of memory and performance. We can now see why the Falcon compiler is going to change the game for expectations dealing with Apache Flex.

The Falcon compiler understands .as, .mxml, .css and .properties files currently.

Gordan states that the parse trees for AS consists of about 100 classes such as LiteralNode, BinaryOperatorNode, ClassNode etc. (Wow this really sounds familiar!, jasblocks ) I’m not even comparing the two but it’s nice to know the 2 years I worked on studying parsers, lexers and AS DOM is not going to waste. The MXML parse tree looks the same with nodes such as MXMLDocumentNode, MXMLInstanceNode, MXMLScriptNode, etc.

Falcon uses 3rd party grammars to create the various lexers, parsers and code generators with ANTLR, JFlex and JBurg parser generators.

MXML is compiled directly to ABC, not AS source code or AS parse tree.

Well, as you can see this is definitely the land of OZ for tooling developers once this is released. There is always a chance I could be wrong but having enough experience with this parsing stuff, I would say there are some very interesting days ahead regarding Apache Flex’s new engine!

Mike