kamicane / nodes Goto Github PK

I've gotten a lot of mileage out of the def syntax I developed for my ast-types library: https://github.com/benjamn/ast-types/blob/master/def/core.js. It's definitely similar in spirit to your describe function, but I believe it has some advantages:

• Multiple interface inheritance, so that e.g. a FunctionDeclaration can count as both a Function (a subtype of Node that serves as the common supertype of FunctionDeclaration, FunctionExpression, and ArrowFunctionExpression) and a Declaration (a subtype of Statement). This means instanceof no longer works, but it also means we can check subtype relationships in constant time, rather than having to traverse the prototype chain.
• A single namespace for AST types, so that types can be more easily forward- and/or recursively-declared. For example, def("Identifier") is used many times before it is finally defined. Types are referred to by their string names using the def function, e.g. def("ObjectExpression"), and those types are cached by name, so you don't have to worry about passing around references to types, or accidentally creating multiple types with the same name.
• The ability to define types incrementally, across multiple files. For example, the def("Function") type has only id, params, and body fields when first defined, but it incrementally acquires additional fields if you include the lib/es6.js or lib/es7.js files.
• A way of providing defaults for properties that may be missing. For example, a TryStatement can have either a handler or handlers field, since there was some confusion between the Mozilla Parser API and Esprima about which was correct, and the other field will be automatically generated if need be.
• Automatic generation of type-checked node builder functions (require("ast-types").builders), type checking functions (require("ast-types").namedTypes), and (hopefully soon) documentation. The sky is the limit here, once you have a good declarative syntax for defining the grammar.

The reason I think it would be worthwhile to settle on a standard syntax we can both use is that we have the opportunity to provide the only truly machine-executable specification of the ES6+ grammar. Esprima certainly doesn't capture all the necessary type requirements, the Mozilla Parser API is pretty far out of date at this point, and the ES6 grammar is scattered all over the specification document, is not directly useful for programming purposes, and doesn't really match the Esprima AST type system.

If we can settle on a common syntax (I'm happy to call it describe instead of def, if you prefer), and perhaps move the type descriptions into a standalone project, I'm confident our specification will become the most complete and useful reference for the grammar as it continues evolving.

What do you think?

I need to have a list with all nodes or, alternatively, be able to query by position in the code, for example all the nodes which start between line 10 and 25.
It's possible to have any of these things?

Anyway thank you for this library!