incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Schmalle <apa...@teotigraphix.com>
Subject Re: [FlaconJS] pseudo emitter algorithm
Date Sun, 02 Dec 2012 20:11:18 GMT
Does this mean like expression statements first, statements second,  
blocks next etc?

Mike

Quoting Gordon Smith <gosmith@adobe.com>:

> The bottom-upness of the BURM means that subtrees that are nearer to  
> the leaves of the AST get reduced before subtrees that nearer to the  
> root. Trees in computer science grow from the top down.
>
> Sent from my iPad
>
> On Nov 30, 2012, at 10:24 PM, "Alex Harui" <aharui@adobe.com> wrote:
>
>> Interesting.  Someday I will figure out what is bottom up about it.
>>
>> Anyway, thanks, and bottoms up!
>>
>> -Alex
>>
>>
>> On 11/30/12 9:48 PM, "Gordon Smith" <gosmith@adobe.com> wrote:
>>
>>> The BURM is the Bottom-Up Rewrite Machine that the BURG or  
>>> Bottom-Up Rewrite
>>> Generator generates. A BURM reduces subtrees within an AST to an  
>>> output format
>>> such as ABC or JS, starting with leaf nodes and working its way upward.
>>>
>>> Sent from my iPad
>>>
>>> On Nov 30, 2012, at 8:45 PM, "Alex Harui" <aharui@adobe.com> wrote:
>>>
>>>> BURM?  What does that stand for anyway?  It might as well have  
>>>> been Burmese.
>>>> It will take a while to understand :-)
>>>>
>>>>
>>>> On 11/30/12 5:36 PM, "Gordon Smith" <gosmith@adobe.com> wrote:
>>>>
>>>>>> 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
>>>>
>>>> --
>>>> Alex Harui
>>>> Flex SDK Team
>>>> Adobe Systems, Inc.
>>>> http://blogs.adobe.com/aharui
>>
>> --
>> 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


Mime
View raw message