flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [FlaconJS] pseudo emitter algorithm
Date Sat, 01 Dec 2012 06:23:57 GMT
Interesting.  Someday I will figure out what is bottom up about it.

Anyway, thanks, and bottoms up!


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
>>>>> - 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.

View raw message