incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Schmalle <>
Subject RE: [FlaconJS] pseudo emitter algorithm
Date Sat, 01 Dec 2012 10:36:44 GMT
Thanks Gordon, you have convinced me to learn JBurg and it's grammar.  
I have enough knowledge of antlr to know sometimes rewriting  
algorithms are faster.

In a way, I bet that JBurg is a lot like antlrs rewritting syntax and  
idea, which I have a lot of experience with. I'm sure it's a lot like  
antlrs tree walker generator (but different :) ).

Enough time has gone by for me to see the wrong assumption I made  
about SWFs involvement in the generation.


Quoting Gordon Smith <>:

>> I don't know SWF format and JBurg
> The SWF and ABC formats are irrelevant if you want to generate JS  
> code, so you wouldn't need to learn them.
> If you don't want to learn about the BURM I suppose you could try  
> generating JS code directly from the AST. I don't know enough about  
> FalconJS to know whether the BURM approach produces more efficient  
> code. Understanding the BURM is not terribly hard, though. There are  
> three main ideas:
> 1. A BURM pattern like
>     Pattern labeledBreakStmt
>     BreakID(IdentifierID(void));
> describes a subtree within the AST; in this case, it is describing  
> the subtree
>     BreakNode
>         IdentifierNode
> that represents code like "break foo";
> 2. A BURM rule like
>     statement = Pattern labeledBreakStmt: 0
>     JBurg.Reduction reducer.reduce_labeledBreakStmt(__p);
> tells the BURM what to do when it finds such a subtree: namely, call  
> the Java method reduce_labeledBreakStmt() in the  
> ASGeneratingReducer, which has a slew of "reduce_XXX()" methods for  
> reducing various subtrees.
> 3. The result of a "reduction" can be any Java object which somehow  
> represents the subtree that got reduced. Often this is an  
> InstructionList but it can be anything. This Java object can then be  
> used in other patterns to describe more general or recursive  
> patterns, as in
>     Pattern blockStmt
>     BlockID(statement stmts*);
> For example, this says that a block statement is a BlockNode with  
> multiple child nodes which have been reduced to a 'statement'.
> The BURM patterns and rules should be mostly the same whether you  
> are generating ABC or JS, because they depend on the AS node  
> patterns that are being noticed and reduced. So I really think you'd  
> be doing most of your work inside the JSGeneratingReducer. I believe  
> this was Bernd's approach when he developed FalconJS. You just make  
> the reduce_XXX() method produce JS strings rather than ABC  
> InstructionLists.
> - Gordon
> -----Original Message-----
> From: Michael Schmalle []
> Sent: Friday, November 30, 2012 4:11 PM
> To:
> Subject: RE: [FlaconJS] pseudo emitter algorithm
> Quoting Gordon Smith <>:
>> I didn't follow the whole discussion. Is the issue that you were
>> planning to work on MXML->JS but Alex and I think
>> MXML->datastructure is a better approach? You don't have to accept
>> what we say. :)
>> - Gordon
> The conversation was about exploring a straight AST to JS convertor
> and bypassing the JS emitting using SWF reducer.
> My point was in the discussion that I don't know SWF format and JBurg
> so trying to maintain FalconJS in it's current state would be hard for
> a lot of developers.
> A lot of cross compilers just work with the straight AST in our case
> the IASNode or IDefinition frameworks.
> I also thought having this ability would allow other targets to be
> implemented more quickly IE Java android or something...
> What do you think?
>> -----Original Message-----
>> From: Michael Schmalle []
>> Sent: Friday, November 30, 2012 3:55 PM
>> To:
>> Subject: RE: [FlaconJS] pseudo emitter algorithm
>> Well considering the conversation between you two, I will ditch
>> pretty much all I said in the last 3 days. This is what I get for
>> living on a mountain...
>> I have interest in the non-flash player stuff, so I guess I will
>> keep up with your conversations.
>> For now, I will focus on testing the compiler and trying to get in a
>> groove somehow dealing with that. I'm going to try and document more
>> of the compiler on the wiki. Gordon feel free the correct me if I'm
>> wrong in places.
>> And, I will try to really understand Alex's prototype and see if I
>> can get my brain wrapped around that to help with some simple test
>> components.
>> Mike
>> Quoting Gordon Smith <>:
>>> That sounds fine. We'll work in parallel:
>>> Me: MXML->ABC
>>> You: MXML->datastructure, first for use in AS/ABC, then for use in JS
>>> - Gordon
>>> -----Original Message-----
>>> From: Alex Harui []
>>> Sent: Friday, November 30, 2012 3:29 PM
>>> To:
>>> Subject: Re: [FlaconJS] pseudo emitter algorithm
>>> On 11/30/12 3:22 PM, "Gordon Smith" <> wrote:
>>>> MXML->JS doesn't exist and is not the way to go.
>>>> MXML->datastructure is a good idea. Alex will do it first for
>>>> MXML->interpretation
>>>> by JS and later for interpretation by an ABC library written in AS.
>>> I'm pretty sure I had this all working last year in AS.  I just have
>>> to dust it off.  Right now it is easier/faster for me to debug in AS,
>>> so I will probably do the AS version first, but I will be keeping all
>>> of the old ABC code paths around.  Right now there is some global flag
>>> that determines which code paths to go down.  I might tie that to some
>>> new property in flex-config.xml or something like that.
>>> --
>>> Alex Harui
>>> Flex SDK Team
>>> Adobe Systems, Inc.
>> --
>> Michael Schmalle - Teoti Graphix, LLC
> --
> Michael Schmalle - Teoti Graphix, LLC

Michael Schmalle - Teoti Graphix, LLC

View raw message