incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Smith <gosm...@adobe.com>
Subject Re: [FlaconJS] pseudo emitter algorithm
Date Sun, 02 Dec 2012 21:45:38 GMT
That's right.

Sent from my iPad

On Dec 2, 2012, at 12:12 PM, "Michael Schmalle" <apache@teotigraphix.com> wrote:

> 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