2010/2/26 Joseph Schorr (יוסף שור) <[email protected]>:
> Would we also have a defined, common format for representing types? I think
> that would be critical for sharing some of the more advanced optimization
> phases.
I don't know. Caja's optimizations have a very simplistic notion of type.
An expression can be typed as
truthy or falsey
where (x) is truthy iff !!(x) always either fails to exit normally or
yields true.
or falls into the following type hierarchy
object
null
reference => truthy
function
primitive
string
number
boolean
undefined
Coming up with a way of representing facts about expressions would be great.
A fact might be
this node always evaluates to the same value as this simpler
non-side effecting expression
this node is never reached
this node exits abnormally or produces a value with this closure type
the author asserted that this node has a given closure type
We could store such info in the "annotations" and/or "inferences"
properties of nodes.
> Thanks,
> Joey
>
> On Fri, Feb 26, 2010 at 4:33 PM, Mike Samuel <[email protected]> wrote:
>>
>> I want to do do some integration between my project, Caja, and others
>> like GWT and the Closure Compiler.
>> Although each project is implemented in Java, each has their own
>> syntax tree implementation : com.google.caja.parser.ParseTreeNode,
>> com.google.gwt.dev.js.ast.JsNode, com.google.javascript.rhino.Node.
>>
>> What do people think about using something like
>> http://code.google.com/p/es-lab/wiki/JsonMLASTFormat as a common
>> interchange format? If each project could serialize / deserialize
>> parse trees to and from this format, then it might be possible to
>> separate out some of the generally useful optimization and analysis
>> passes each contains.
>>
>> This format can store meta-information (e.g., source location info)
>> that is not part of the parse tree in a way that can round trip well
>> and that would get lost if javascript source were used as the
>> interchange format. It can also work well with systems that produce
>> invalid parse trees as intermediate forms, e.g. with hanging elses and
>> numeric literals that might render as references to masked variables
>> prior to alpha-renaming.
>>
>> Any other projects that might benefit from this? YUI compressor seems
>> to use a variant of the codebase that Closure does, and Dojo
>> shrinksafe seems to use the same but doesn't build a parse tree.
>>
>> cheers,
>> mike
>
>
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
