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 gosmith@adobe.com designates
 64.18.1.208 as permitted sender)
From: Gordon Smith <gosmith@adobe.com>
To: "flex-dev@incubator.apache.org" <flex-dev@incubator.apache.org>
Date: Fri, 30 Nov 2012 15:22:02 -0800
Subject: RE: [FlaconJS] pseudo emitter algorithm
Thread-Topic: [FlaconJS] pseudo emitter algorithm
Thread-Index: Ac3PTVS9GjAwBOZcRB2Q1OS9uIpoIgAAa9ArAABWydA=
Message-ID: 
 <149F8129B58B2D418508E63117D9C5419B5B4CFD47@nambx05.corp.adobe.com>
References: <50B93885.1020200@gmail.com> <CCDE7B6E.494BB%aharui@adobe.com>
In-Reply-To: <CCDE7B6E.494BB%aharui@adobe.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

I think I agree with everything you said, Alex.

Here's my take:

AS->ABC is already done in Falcon, modulo some bug fixes.
AS->JS is kinda done in FalconJS but needs work and we may want to change i=
t to emit different JS patterns.
MXML->ABC is 80% done in Falcon and worth completing. I'm working on determ=
ining what works, what doesn't, and fixing problems.
MXML->JS doesn't exist and is not the way to go.
MXML->datastructure is a good idea. Alex will do it first for interpretatio=
n by JS and later for interpretation by an ABC library written in AS.

- Gordon

-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com]=20
Sent: Friday, November 30, 2012 3:04 PM
To: flex-dev@incubator.apache.org
Subject: Re: [FlaconJS] pseudo emitter algorithm

OK, what did I write that is confusing everybody?

IIUC, MXML is parsed into a different set of nodes which are then visited i=
n the tree walk to generate ABC codes directly.  When compiling the AS in a=
n MXML script block or a .AS file, the AS AST nodes go through Jburg and ev=
entually become ABC.

FalconJS only overrides the AS AST nodes to generate JS.  I don't think it =
will generate anything for MXML, but I haven't tried it.

MXML -> ABC is mostly or all in MXMLClassDirectiveProcessor.java.

I think FalconJS will have to swap/overlay/override what that class does to=
 generate JS.

What MXML currently resolves to in ABC is the equivalent of a bunch of func=
tions that construct the tags in the MXML.  For many reasons which I have m=
entioned before, I am planning to change the ABC that it generates to gener=
ate a data structure.  And then FalconJS will need to generate the same dat=
a structure in JS.

Does that help?

On 11/30/12 2:51 PM, "Daniel Wasilewski" <devudesign@gmail.com> wrote:

> I'm trying to follow, but I feel the same.
>=20
> My main confusion came from the one thing. I've got in my mind AST is=20
> just AST. Abstract by definition. It represents a code logic in=20
> abstract form.
> Why JS would collide with AS? Why the Falcon after AST coming back to=20
> AS? AST says, create class, create method, create method body,=20
> expression and evaluate it.
> And now if JS is a target should have grammar definition how to create=20
> a class, method and represent evaluation. Am I missing a point of=20
> compilers, parsers etc?
>=20
>=20
> On 11/30/2012 7:41 PM, Michael Schmalle wrote:
>> Ok, I'm a bit confused but my brain is probably going to explode any=20
>> minute and that is about all from me for a bit.
>>=20
>> I'll just sit back and see if any other conversations come up about=20
>> as
>> -> js. Maybe I'm crazy and just want to create more work for myself.
>>=20
>> Maybe the way it stands ABC -> js is good enough for now?
>>=20
>> Mike
>>=20
>>=20
>> Quoting Alex Harui <aharui@adobe.com>:
>>=20
>>>=20
>>>=20
>>>=20
>>> On 11/30/12 11:05 AM, "Michael Schmalle" <apache@teotigraphix.com>
>>> wrote:
>>>=20
>>>> Quoting Gordon Smith <gosmith@adobe.com>:
>>>>=20
>>>>> I don't object to generating a data structure for V11, but I think=20
>>>>> that it makes more sense to do that as a second phase after ABC=20
>>>>> generation is working. Otherwise there are a lot of moving parts=20
>>>>> and progress will be slower.
>>>>=20
>>>> Correct me if I'm wrong Alex, but Gordon, I think Alex was talking=20
>>>> about JavaScript data structures produced during crosscompile of MXML.
>>> No, for both AS and JS so we have the same code paths.  But fear=20
>>> not, the the work I did last year has a switch and all the old code=20
>>> paths are retained.
>>>=20
>>> I accept Gordon's argument that we can finish MXML handling faster=20
>>> by getting Falcon to generate the old code patterns.
>>>>=20
>>>=20
>>> --
>>> Alex Harui
>>> Flex SDK Team
>>> Adobe Systems, Inc.
>>> http://blogs.adobe.com/aharui
>>>=20
>>>=20
>>=20
>=20

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