Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of devudesign@gmail.com
 designates 209.85.212.179 as permitted sender)
Message-ID: <50CBB6FA.2030301@gmail.com>
Date: Fri, 14 Dec 2012 23:32:10 +0000
From: Daniel Wasilewski <devudesign@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: flex-dev@incubator.apache.org
Subject: Re: [FalconJx] Prototype ActionScript -> JavaScript compiler code
 up in svn
References: <20121214130457.10314tr6jq3ms4zt@franklin.liquidweb.com>
 <CCF0B0FF.4A073%aharui@adobe.com>
 <149F8129B58B2D418508E63117D9C5419B5B62476B@nambx05.corp.adobe.com>
In-Reply-To: 
 <149F8129B58B2D418508E63117D9C5419B5B62476B@nambx05.corp.adobe.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Maybe initial design of FalconJS was design for future Flex Builder in 
mind. I have seen some demo showing how cool will be to see changes on 
runtime without compiling a project, but it was done in AS3. BURM will 
definitely be the way to go in that case. But just wonder if both 
solutions can actually work together under one enviroment and produce 
the same output? Or even help to optimise the code?

On 12/14/2012 7:31 PM, Gordon Smith wrote:
> 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:aharui@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" <apache@teotigraphix.com> wrote:
>
>> Quoting Alex Harui <aharui@adobe.com>:
>>
>>>
>>>
>>> On 12/14/12 4:24 AM, "Erik de Bruin" <erik@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
>