Bernd Paradies may have had a different reason for using the BURM... I don't really know.
- Gordon -----Original Message----- From: Michael Schmalle [mailto:apa...@teotigraphix.com] Sent: Friday, December 14, 2012 12:03 PM To: flex-dev@incubator.apache.org Subject: RE: [FalconJx] Prototype ActionScript -> JavaScript compiler code up in svn Thanks Gordon! The really answered a question I had and also explains why you didn't just use the ANTLR rewriter to create the tree or nodes during parsing. I really understand now. And as you said, a top down walk should work for what we have to do and it is quite maintainable. Which will mean more development from more devs. Our current plans involve running generated js through googles closure compiler which drastically optimizes the code before it even gets to the browser's parser and compiler. Thanks for the info. Mike Quoting Gordon Smith <gosm...@adobe.com>: > I would be surprised if the BURM is faster than a simple top-down walk. > > The main advantage of using a BURM is that it allows for optimizations > to be easily coded as alternate reductions with lower cost. Typically > there are many difference sequences of bottom-up reductions that could > be applied to reduce the tree, and the BURM actually computes the > *lowest-cost* sequence out of all possible sequences. (It is solving > a complicated optimization problem, although in an efficient way.) > > As a trivial example, in addition to writing a reduction for > > expression + expression > > that reduces > > a + b > > to instructions like > > push a > push b > add > > and > > 1 + 2 > > to (inefficient) instructions like > > push 1 > push 2 > add > > you can write a reduction for > > constant + constant > > and assign it a lower "cost" so that > > 1 + 2 > > reduces to > > push 3 > > In the case of JavaScript, I'll bet that today's JavaScript engines > are good at doing various optimizations, so I don't see why an > AS->JS cross-compiler needs to do them in advance using a BURM. > > - Gordon > > -----Original Message----- > From: Alex Harui [mailto:aha...@adobe.com] > Sent: Friday, December 14, 2012 10:34 AM > To: flex-dev@incubator.apache.org > Subject: Re: [FalconJx] Prototype ActionScript -> JavaScript compiler > code up in svn > > > > > On 12/14/12 10:04 AM, "Michael Schmalle" <apa...@teotigraphix.com> wrote: > >> >> Quoting Alex Harui <aha...@adobe.com>: >> >>> >>> >>> >>> On 12/14/12 4:24 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: >>> >>>> Dude, >>>> >>>> "goog" it is. >>>> >>>> I just needed a little pep-talk, I guess ;-) >>> Right now, I'm trying to get FalconJS to compile an MXML file and >>> output the goog stuff. That work got delayed because there were >>> more distractions from the 4.9 release than I expected. Then I will >>> try to get the BURM/Reducer/Emitter to do the same. Mike sent me >>> what he tried to do in this area so I can reference it if needed. >>> >>> We are definitely in prototype/research mode and different angles >>> should be investigated. The key to the "Apache Way" is that if we >>> have to make choices in deciding what to ship, it should be done on >>> technical merit. >> >> What context are you speaking from? compiler, js framework? > In theory, everything in Apache is decided on technical merit. If > your version of AS to JS turns out to be faster and easier to > maintain, it will win. > > It will be interesting to figure out what to do if the BURM version is > significantly faster, but my gut says that won't be the case. > > > -- > 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
