incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Wasilewski <devudes...@gmail.com>
Subject Re: [FlaconJS] pseudo emitter algorithm
Date Mon, 03 Dec 2012 01:35:00 GMT
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