incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Smith <>
Subject RE: [FlaconJS] pseudo emitter algorithm
Date Fri, 30 Nov 2012 23:22:02 GMT
I think I agree with everything you said, Alex.

Here's my take:

AS->ABC is already done in Falcon, modulo some bug fixes.
AS->JS is kinda done in FalconJS but needs work and we may want to change it to emit different
JS patterns.
MXML->ABC is 80% done in Falcon and worth completing. I'm working on determining what works,
what doesn't, and fixing problems.
MXML->JS doesn't exist and is not the way to go.
MXML->datastructure is a good idea. Alex will do it first for interpretation by JS and
later for interpretation by an ABC library written in AS.

- Gordon

-----Original Message-----
From: Alex Harui [] 
Sent: Friday, November 30, 2012 3:04 PM
Subject: Re: [FlaconJS] pseudo emitter algorithm

OK, what did I write that is confusing everybody?

IIUC, MXML is parsed into a different set of nodes which are then visited in the tree walk
to generate ABC codes directly.  When compiling the AS in an MXML script block or a .AS file,
the AS AST nodes go through Jburg and eventually become ABC.

FalconJS only overrides the AS AST nodes to generate JS.  I don't think it will generate anything
for MXML, but I haven't tried it.

MXML -> ABC is mostly or all in

I think FalconJS will have to swap/overlay/override what that class does to generate JS.

What MXML currently resolves to in ABC is the equivalent of a bunch of functions that construct
the tags in the MXML.  For many reasons which I have mentioned before, I am planning to change
the ABC that it generates to generate a data structure.  And then FalconJS will need to generate
the same data structure in JS.

Does that help?

On 11/30/12 2:51 PM, "Daniel Wasilewski" <> wrote:

> I'm trying to follow, but I feel the same.
> My main confusion came from the one thing. I've got in my mind AST is 
> just AST. Abstract by definition. It represents a code logic in 
> abstract form.
> Why JS would collide with AS? Why the Falcon after AST coming back to 
> AS? AST says, create class, create method, create method body, 
> expression and evaluate it.
> And now if JS is a target should have grammar definition how to create 
> a class, method and represent evaluation. Am I missing a point of 
> compilers, parsers etc?
> On 11/30/2012 7:41 PM, Michael Schmalle wrote:
>> Ok, I'm a bit confused but my brain is probably going to explode any 
>> minute and that is about all from me for a bit.
>> I'll just sit back and see if any other conversations come up about 
>> as
>> -> js. Maybe I'm crazy and just want to create more work for myself.
>> Maybe the way it stands ABC -> js is good enough for now?
>> Mike
>> Quoting Alex Harui <>:
>>> On 11/30/12 11:05 AM, "Michael Schmalle" <>
>>> wrote:
>>>> Quoting Gordon Smith <>:
>>>>> I don't object to generating a data structure for V11, but I think 
>>>>> that it makes more sense to do that as a second phase after ABC 
>>>>> generation is working. Otherwise there are a lot of moving parts 
>>>>> and progress will be slower.
>>>> Correct me if I'm wrong Alex, but Gordon, I think Alex was talking 
>>>> about JavaScript data structures produced during crosscompile of MXML.
>>> No, for both AS and JS so we have the same code paths.  But fear 
>>> not, the the work I did last year has a switch and all the old code 
>>> paths are retained.
>>> I accept Gordon's argument that we can finish MXML handling faster 
>>> by getting Falcon to generate the old code patterns.
>>> --
>>> Alex Harui
>>> Flex SDK Team
>>> Adobe Systems, Inc.

Alex Harui
Flex SDK Team
Adobe Systems, Inc.

View raw message