Falcon

AST

IASNode

toString and -dump-ast=true

mxmlc options?

MXML: the Falcon compiler turns MXML AST into straight ABC instructions.

"I don't see why you would need to transform the MXML AST into yet another model. There are already two models for MXML and they should be sufficient.

The syntactic model produced from the MXML tokens is MXMLData. Like any XML DOM, it simply represents the nesting of the tags, their attributes, and the text inside, without attributing any meaning to anything.

The semantic model for MXML is the MXML AST, which has determined what every tag, attribute, and piece of text means. For example, it has understood that when you write <s:Button label="OK" color="red" click="doit()"/> you are creating an instance of spark.components.Button, setting the label property to "OK", setting the color style to 0xFF0000, and adding an event handler to handler the click event. The MXML tree captures every piece of semantic information that was in the MXML file."

"But if you prefer to turn MXML into JavaScirpt source code, it should be straightforward to do that. The MXMLClassDirectiveProcessor is a simple recursive descent through the MXML AST. The main complexity is that it can't simply generate a continuous stream of code in tree order. For example, an attribute value that is a databinding expression has to generate all sorts of extra stuff like Watcher instances in other places."

FalconJS

FalconJS is a project started by Alex Harui. It is currently the most
complete implementation and has (limited?) MXML parsing. The FalconJS
compiler will take an MXML and AS project and output a valid HTML/JS
application. FalconJS does depend on a custom AS framework (i.e. won't
work with the Flex SDK) and corresponding JS framework. This framework
goes by the name of FlexJS. Read more about it on the Wiki:

https://cwiki.apache.org/confluence/display/FLEX/Alex%27s+FlexJS+Prototype|../../../../../../../../../display/FLEX/Alex%27s+FlexJS+Prototype|\

"I may be missing something, but I think the MXMLClassDirectiveProcessor is
walking the AST not some intermediate model.  What it does is a bit tricky
because it is trying to flatten the tree into the data array and use the
same APIs (of passing around Contexts).  I haven't looked at your walker
recently, but it might be simpler to implement in the walker/visitor
pattern."

FalconJx

FalconJx is the 'alternative' project from Michael Schmalle. It uses
an alternative approach to AS3 compilation (don't ask for details, I
have no clue about the innards of that code). One of it's main selling
points (from my humble point of view) is that it has a very flexible
architecture for outputting different flavours of JS. The status of
this project is that we are working on getting complete AS3 language
feature coverage in place. This means that we are working towards
~100% translation of AS into JS. I'm using the Google Closure Tools to
augment standard JS to try and match the original AS language
features. This is coming along nicely, but I'm sure the devil will be
in the details. Read more on the 'goog' way here:

https://cwiki.apache.org/confluence/display/FLEX/AS+to+JS+the%27goog%27+Way|../../../../../../../../../display/FLEX/AS+to+JS+the%27goog%27+Way|\

FalconJx future: once we have AS (and hopefully MXML, at some point)
translating into JS and have functional tests in place, the challenge
will become to come up with both AS and JS framework to actually allow
for application development. I'm silly enough to still cling to the
idea that we'll be able to use (most of) the Flex SDK and create a
compatible JS library... but I'm sure others will declare me insane
for just dreaming about that :-)

What FalconJx is at the moment is a cross compiler for ActionScript business logic to JavaScript business logic.

FalconJx is being designed to be able to compile ActionScript3 source code business logic to JavaScript business logic. "When I say business logic, I mean, no views, no ui components, no flash display list to javascript DOM conversations. Just business logic."

The parser
-------------------

AST stands for Abstract Syntax Tree avery complicated way of saying Objects that have parents and children. When an .as file is parsed by Falcon, the parser creates "blocks" of things it recognizes from the string tokens feed to it as it's running through the source file. A token is a String defined my the AS3 language spec IE "class", "if", "{", "foo" etc.

As the parser accepts these tokens from the stream, it recognizes patterns like "public" is a namespace if it happens just before the "class" token. So as the parser runs through these rules and finds matches, it creates IASNode instance such as IClassNode, IIdentifier node etc.

Each node in the tree represents a part of the ActionScript file. If you actually look at an .as you can see how it's very nature is heiracle, that is the AST tree and the IASNode subclasses represent that tree.

We can also call this tree a DOM or Document Object Model. So when we say AST we also mean ActionScript DOM because there is only one semantic way that DOM will be constructed by the ASParser's grammar. It's exactly what a Browser does with the HTML DOM, there are rules and the only way the browser's parser will create an element in the DOM is if you source code matches the rules.

The walker
-------------------------

Just as you would create a recursive function to traverse HTML with JavaScript, we can do the same thing with the AS3 DOM (AST) which I have done.

The only hard part about this is you have to be familiar with the "grammar" or API of the DOM to make sure you recursively traverse it in the correct order and get everything. That is why Erik and I have over 500 unit tests, this is making sure we are producing the whole language correctly.

So once the DOM is created, we call walke.visitFile(fileNode), which the IFileNode is the root of the tree, just like window is the root of the HTML DOM.

Visit file will then abstractly call visitPackage(), then visitClass(), then visitMethod(), visitBlock(), visitIf(), visitBinary() etc. The visit methods are called through the node switch strategy class. This is kindof complicated but not really, it's kindof a juggling act back and forth so the whole node handler traversing calls the correct visit method based on the current node's type, is it a function, expression etc.

You see, that when each of the nodes in the tree are visited recursively, the String emitter is called to emit the javascript or actionscript source code into the buffer.

The backend
----------------------------

The backend stuff is going to be refactored and I have some ideas about the compiler setup but basically, the way the actual compiler is setup and the design of FalconJx, it allows tremendous flexibility on overriding things for different JavaScript output,  the final string that gets written to disk with the .js extension.

Like right now Erik has a Goog and AMD output that are separate implementations but use the same core framework.

On a final note, this framework was first written by me to create valid ActionScript. So what is actually happening is we are taking advantage of the fact JavaScript is ECMA just like AS, so we are only overriding the parts of the two languages that differ for source code production.

In the end, FalconJx is actually an ActionScript emitter first, other languages next.

FlexJS

GPU rendering (Starling?)

The FalconJS compiler in compiler.js, plus the FlexJSTest_again example and
the framework in the asjs develop branch already take MXML and result in an
HTML DOM.

The 'goog' way

AMD - RequireJS

  • No labels

1 Comment

  1. Anonymous

    Is this (ASJS) dead now? No changes since January...