Thanks Gordon, you have convinced me to learn JBurg and it's grammar.
I have enough knowledge of antlr to know sometimes rewriting
algorithms are faster.
In a way, I bet that JBurg is a lot like antlrs rewritting syntax and
idea, which I have a lot of experience with. I'm sure it's a lot like
antlrs tree walker generator (but different :) ).
Enough time has gone by for me to see the wrong assumption I made
about SWFs involvement in the generation.
Mike
Quoting Gordon Smith <gosm...@adobe.com>:
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:apa...@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 <gosm...@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:apa...@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 <gosm...@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:aha...@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" <gosm...@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
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
