That's right. Sent from my iPad
On Dec 2, 2012, at 12:12 PM, "Michael Schmalle" <apa...@teotigraphix.com> wrote: > Does this mean like expression statements first, statements second, > blocks next etc? > > Mike > > Quoting Gordon Smith <gosm...@adobe.com>: > >> 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" <aha...@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" <gosm...@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" <aha...@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" <gosm...@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:apa...@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 <gosm...@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:apa...@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 <gosm...@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:aha...@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" <gosm...@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 >
