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 22:31:03 GMT
I think the point was;

- Tree parsers such as the AS3Parser creates a Tree from the parent  
node down to child aka Recursive Decent Parser.

- Tree walkers such as the BURM walk a parse tree from the child nodes  
up to the parent IE Bottom Up

Mike


Quoting Daniel Wasilewski <devudesign@gmail.com>:

> huh?
>
> In computer science both conventions are adopted afik. Not reserved,  
> that someone can say, there is only 1 correct.
> Polish notation or reversed polish notation is correct in computer science?
>
> On 12/2/2012 8:07 PM, Gordon Smith wrote:
>> 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