Patrick Steele • almost 9 years ago
Builder API
The Mozilla Parser API allows for `builder` callbacks to create custom data types (see the link below). While we are not going to be using the Reflect.parse, can we utilize CustomExpression and CustomStatement nodes in our AST?
https://developer.mozilla.org/en-US/docs/SpiderMonkey/Parser_API#Builder_objects
Comments are closed.
4 comments
nwinter Manager • almost 9 years ago
Does this enable some sort of feature we wouldn't otherwise be able to do? We would have to add support for transforming those CustomExpression and CustomStatement nodes back into standard AST before our other tools (like our AST normalizer, JS_WALA) operated. I think I can do this in my pre-normalization transforms if it is needed, but that does happen pretty early on, so we'd only be able to use the CustomExpression and CustomStatement nodes for Step 5 of the "How does it work?" list here: http://aetherjs.com/
Let me know what you're thinking!
Rob Blanckaert • almost 9 years ago
My understanding of builder objects is they allow you to use the existing parser (or a parser you create yourself) to return an AST in a format other then one specified in that document and used by escodegen and friends.
The logic is instead of the parser creating the objects as described in the Node section by hand, it instead calls those builder methods on some supplied object. The default builder methods just generate the tree as described but if the caller of the parser wanted a different representation ( for example generating a string representing the source code of a different language without first going though the JS AST ) they could pass an objet with their own builder methods. My reading of the documentation is that CustomStatement and CustomExpression are just placeholders to mean "whatever data type the builder wants." The parser doesn't care what your representation looks like because it either just returns it or passes it as arguments to your other builder function.
Patrick Steele • almost 9 years ago
The goal is to avoid having to create an AST all the way down to the bare metal of an implementation. My specific motivating example is the Scheme numeric tower; I wrap standard JS numerics in custom datatypes that allow for exact and inexact arithmetic. From my understanding the final result needs to be an AST, and so I would need to convert this code to a JS AST as well. With the CustomX expressions I could simply have a SchemeNumber as a final node, which otherwise would represent a substantially-sized subtree.
nwinter Manager • almost 9 years ago
Hmm, I think I understand. I don't think our tooling will support preserving those custom node types throughout the transpilation process, though. After user code is parsed into an AST, that AST is normalized by JS_WALA, then turned into JavaScript again by escodegen, then parsed again by Esprima so that we can run most of our Aether transformations on the result, then fed through traceur, etc. Your runtime would only again get access to the custom node after all that, none of which knows what to do with a SchemeNumber.