royale-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aha...@apache.org
Subject [royale-compiler.wiki] branch master updated: Updated Developer Guide (markdown)
Date Fri, 01 Jun 2018 00:42:20 GMT
This is an automated email from the ASF dual-hosted git repository.

aharui pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/royale-compiler.wiki.git


The following commit(s) were added to refs/heads/master by this push:
     new 2fd6fde  Updated Developer Guide (markdown)
2fd6fde is described below

commit 2fd6fde97a3360c1b9a462165ddcf2b216b454c1
Author: aharui <aharui@apache.org>
AuthorDate: Thu May 31 17:42:18 2018 -0700

    Updated Developer Guide (markdown)
---
 Developer-Guide.md | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/Developer-Guide.md b/Developer-Guide.md
index 3fdbb4d..512b0f1 100644
--- a/Developer-Guide.md
+++ b/Developer-Guide.md
@@ -34,10 +34,12 @@ The compiler-jx project also introduces the concept of a "target" which
is a set
 
 Pretty much all targets start execution the same way:  They build an Abstract Syntax Tree
(AST).  An AST is a tree data structure with nodes that represent the parsed source code.
 The top of the tree is a FileNode and usually the first child is a PackageNode and children
of that might be ImportNodes and a ClassNode and children of the ClassNode will be FunctionNodes
that contain ParameterNodes and ExpressionNodes and so on.  At the bottom of the tree should
be IdentifierNodes and Litera [...]
 
-What happens next is different for SWF output vs JavaScript output.  In the SWF output, the
JBurg "reducer" is called to reduce patterns of nodes into SWF output byte code.  This reducer
works from the bottom of the tree upward.  This supposedly makes it easier and more efficient
to identify possible optimizations such as collapsing constant expressions, and identify semantic
errors.
+What happens next is different for SWF output vs JavaScript output.  In the SWF output, the
JBurg "reducer" is called to reduce patterns of nodes into SWF output byte code.  This reducer
works from the bottom of the tree upward.  This supposedly makes it easier and more efficient
to identify possible optimizations such as collapsing constant expressions, and identify semantic
errors.  However, the syntax for describing tree patterns is complex and not very approachable
to people new to t [...]
 
 The JavaScript output also runs the reducer to help identify semantic errors.  But if none
are found it then walks the AST from the top FileNode down, along the way "emitting" whatever
output is desired.  There are emitters that just output the ASDoc into JSON files which is
how we generate our ASDoc today.  There is an emitter that outputs ActionScript just to prove
that the AST has not lost information.  There is an emitter than outputs vanilla JavaScript.
 But the main emitter class ( [...]
 
+During reduction or the tree walk, nodes are 'resolved' into 'definitions'.  If there is
a variable 'foo', the compiler needs to know if it is a variable (VariableDefinition) or parameter
(ParameterDefinition) or a method (FunctionDefinition).  There are plenty of other Definitions
not mentioned in this paragraph.
+
 ### Emitter Details
 
 This section gives a brief overview of the classes involved in an Emitter.
@@ -51,3 +53,11 @@ This section gives a brief overview of the classes involved in an Emitter.
 * **MXMLRoyaleBlockWalker.java** This should also look like a standard tree walking algorithm
with 'visit' methods for each of the nodes.
 * **JSRoyaleEmitter.java**  This emitter has methods to emit JavaScript for every node. 
Much of the actual output code has been encapsulated in support classes like IdentifierEmitter
and LiteralEmitter to make it easier to re-use these emitters when customizing output.
 * **MXMLRoyaleEmitter.java** This emitter has methods for each MXML AST node.  However, MXML
is output mostly as a data structure, and not as much JavaScript.  So the methods build up
that data structure.
+
+### Notes
+
+Nobody is claiming that the architecture and implementation of the compiler is optimal. 
The code represents what we had time to do in order to get proofs-of-concepts up and running.
 Ideally, the Transpiler would do its own semantic analysis so the source wouldn't get processed
by both a reducer and the tree walker.  Volunteers are welcome to make that happen.
+
+The tree walk might also benefit from other optimizations.  There isn't much state retained
about the parent chain of nodes but many times the emitter must walk up the parent chain to
better understand what to output.
+
+Also, identifiers might be resolved too many times instead of figuring out a smart way to
cache the resolved identifier's definition or optimize the resolving if you know it should
be a member of a class.
\ No newline at end of file

-- 
To stop receiving notification emails like this one, please contact
aharui@apache.org.

Mime
View raw message