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
