My statement was overly broad. All I meant was that the acronym BURM refers to a tree whose root is at the top. Everyone is free to orient their trees as they wish.
Sent from my iPad On Dec 2, 2012, at 5:35 PM, "Daniel Wasilewski" <devudes...@gmail.com> wrote: > 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 <devudes...@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" <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 >
