Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of devudesign@gmail.com designates
 209.85.220.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <6C977545-ADE9-45B5-B9CA-9E751D218D1D@adobe.com>
References: <CCDEE27D.494FF%aharui@adobe.com>
	<05AE47C3-E3FA-49ED-ADB8-6F32A8DB8006@adobe.com>
	<50BBD36C.70606@gmail.com>
	<20121202173103.33395ir2uh7hv4pz@teotigraphix.com>
	<50BC01C4.6090409@gmail.com>
	<6C977545-ADE9-45B5-B9CA-9E751D218D1D@adobe.com>
Date: Mon, 3 Dec 2012 10:15:15 +0000
Message-ID: 
 <CAO8za8OjxTv=P4eEG6d598aVMJe5hYLhAMK2oqEU-nrhc+rA6w@mail.gmail.com>
Subject: Re: [FlaconJS] pseudo emitter algorithm
From: Daniel Wasilewski <devudesign@gmail.com>
To: flex-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=14dae9cdc93d83ed2504cff006ef

--14dae9cdc93d83ed2504cff006ef
Content-Type: text/plain; charset=ISO-8859-1

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 <gosmith@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" <devudesign@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 <devudesign@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" <aharui@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" <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
> >>>>> --
> >>>>> Alex Harui
> >>>>> Flex SDK Team
> >>>>> Adobe Systems, Inc.
> >>>>> http://blogs.adobe.com/aharui
> >
>

--14dae9cdc93d83ed2504cff006ef--