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 aharui@adobe.com designates
 64.18.1.33 as permitted sender)
From: Alex Harui <aharui@adobe.com>
To: "flex-dev@incubator.apache.org" <flex-dev@incubator.apache.org>
Date: Fri, 30 Nov 2012 20:44:43 -0800
Subject: Re: [FlaconJS] pseudo emitter algorithm
Thread-Topic: [FlaconJS] pseudo emitter algorithm
Thread-Index: Ac3PWISjFu9mUSEdRrWKVihmc5jzxgACSi2gAAc50t4=
Message-ID: <CCDECB3B.494EF%aharui@adobe.com>
In-Reply-To: 
 <149F8129B58B2D418508E63117D9C5419B5B4CFD90@nambx05.corp.adobe.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-Entourage/13.13.0.120411
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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
>=20
> The SWF and ABC formats are irrelevant if you want to generate JS code, s=
o you
> wouldn't need to learn them.
>=20
> If you don't want to learn about the BURM I suppose you could try generat=
ing
> 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:
>=20
> 1. A BURM pattern like
>=20
>     Pattern labeledBreakStmt
>     BreakID(IdentifierID(void));
>=20
> describes a subtree within the AST; in this case, it is describing the su=
btree
>=20
>     BreakNode
>         IdentifierNode
>=20
> that represents code like "break foo";
>=20
> 2. A BURM rule like
>=20
>     statement =3D Pattern labeledBreakStmt: 0
>     JBurg.Reduction reducer.reduce_labeledBreakStmt(__p);
>=20
> 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.
>=20
> 3. The result of a "reduction" can be any Java object which somehow repre=
sents
> 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
>=20
>     Pattern blockStmt
>     BlockID(statement stmts*);
>=20
> For example, this says that a block statement is a BlockNode with multipl=
e
> child nodes which have been reduced to a 'statement'.
>=20
> 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 ar=
e
> 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 stri=
ngs
> rather than ABC InstructionLists.
>=20
> - Gordon
>=20
> -----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
>=20
> Quoting Gordon Smith <gosmith@adobe.com>:
>=20
>> 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. :)
>>=20
>> - Gordon
>=20
> The conversation was about exploring a straight AST to JS convertor
> and bypassing the JS emitting using SWF reducer.
>=20
> 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.
>=20
> A lot of cross compilers just work with the straight AST in our case
> the IASNode or IDefinition frameworks.
>=20
> I also thought having this ability would allow other targets to be
> implemented more quickly IE Java android or something...
>=20
> What do you think?
>=20
>=20
>> -----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
>>=20
>> 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...
>>=20
>> I have interest in the non-flash player stuff, so I guess I will
>> keep up with your conversations.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> Mike
>>=20
>> Quoting Gordon Smith <gosmith@adobe.com>:
>>=20
>>> That sounds fine. We'll work in parallel:
>>>=20
>>> Me: MXML->ABC
>>> You: MXML->datastructure, first for use in AS/ABC, then for use in JS
>>>=20
>>> - Gordon
>>>=20
>>> -----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
>>>=20
>>>=20
>>>=20
>>>=20
>>> On 11/30/12 3:22 PM, "Gordon Smith" <gosmith@adobe.com> wrote:
>>>=20
>>>> 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.
>>>=20
>>> --
>>> Alex Harui
>>> Flex SDK Team
>>> Adobe Systems, Inc.
>>> http://blogs.adobe.com/aharui
>>>=20
>>>=20
>>=20
>> --
>> Michael Schmalle - Teoti Graphix, LLC
>> http://www.teotigraphix.com
>> http://blog.teotigraphix.com
>>=20
>>=20

--=20
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui