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 Mon, 03 Dec 2012 04:12:41 GMT
My statement was overly broad. All I meant was that the acronym BURM refers to a tree whose
root is at the top. Everyone is free to orient their trees as they wish.

Sent from my iPad

On Dec 2, 2012, at 5:35 PM, "Daniel Wasilewski" <devudesign@gmail.com> wrote:

> I do understand differences on conceptual level, but just trying to 
> avoid bold statements as arguments that favours one solution over another.
> Because In computer science on academic level it's all comes down to 
> personal preferences of your teacher unfortunately ;)
> 
> On 12/2/2012 10:31 PM, Michael Schmalle wrote:
>> 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
> 

Mime
View raw message