OK, my apology, overreacted a bit. Sometimes I just need to shout up and read the thing twice...
On 3 December 2012 04:12, Gordon Smith <gosm...@adobe.com> wrote: > 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 > > >
