Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <20121201053644.10364eeqmpiw36ws@teotigraphix.com>
Date: Sat, 01 Dec 2012 05:36:44 -0500
From: Michael Schmalle <apache@teotigraphix.com>
To: flex-dev@incubator.apache.org
Subject: RE: [FlaconJS] pseudo emitter algorithm
References: 
 <149F8129B58B2D418508E63117D9C5419B5B4CFD47@nambx05.corp.adobe.com>
 <CCDE813F.494C9%aharui@adobe.com>
 <149F8129B58B2D418508E63117D9C5419B5B4CFD53@nambx05.corp.adobe.com>
 <20121130185512.13213pozmcenl468@teotigraphix.com>
 <149F8129B58B2D418508E63117D9C5419B5B4CFD60@nambx05.corp.adobe.com>
 <20121130191121.20434fqqbi7p45rd@teotigraphix.com>
 <149F8129B58B2D418508E63117D9C5419B5B4CFD90@nambx05.corp.adobe.com>
In-Reply-To: 
 <149F8129B58B2D418508E63117D9C5419B5B4CFD90@nambx05.corp.adobe.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=ISO-8859-1;
 DelSp="Yes";
 format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) H3 (4.3.11)

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.

Mike

Quoting Gordon Smith <gosmith@adobe.com>:

>> 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 [mailto:apache@teotigraphix.com]
> Sent: Friday, November 30, 2012 4:11 PM
> To: flex-dev@incubator.apache.org
> Subject: RE: [FlaconJS] pseudo emitter algorithm
>
> Quoting Gordon Smith <gosmith@adobe.com>:
>
>> 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 [mailto:apache@teotigraphix.com]
>> Sent: Friday, November 30, 2012 3:55 PM
>> To: flex-dev@incubator.apache.org
>> 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 <gosmith@adobe.com>:
>>
>>> 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 [mailto:aharui@adobe.com]
>>> Sent: Friday, November 30, 2012 3:29 PM
>>> To: flex-dev@incubator.apache.org
>>> Subject: Re: [FlaconJS] pseudo emitter algorithm
>>>
>>>
>>>
>>>
>>> On 11/30/12 3:22 PM, "Gordon Smith" <gosmith@adobe.com> 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.
>>> http://blogs.adobe.com/aharui
>>>
>>>
>>
>> --
>> Michael Schmalle - Teoti Graphix, LLC
>> http://www.teotigraphix.com
>> http://blog.teotigraphix.com
>>
>>
>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
>

-- 
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com