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 Sat, 01 Dec 2012 08:54:48 GMT
LoL :)

On 12/1/2012 6:23 AM, Alex Harui 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
>>>


Mime
View raw message