Moving from dev-platform to dev-tech-js-engine-internals. Previous
conversation at
https://groups.google.com/d/msg/mozilla.dev.platform/Ha7HXLbnGGc/dAlP6RbfsrQJ
On 12/17/13, 1:57 PM, Jeff Walden wrote:
On 12/16/2013 03:09 PM, Gregory Szorc wrote:
Perhaps Reflect.parse() could grow a new option to expose "comment" nodes or
could attach comment metadata to specific node types?
It's really not possible to do the latter. Comments don't appertain to
specific nodes at all. They're just random non-token things interspersed in
the token stream. Note that the Esprima stuff mentioned in the other email
doesn't attempt to put comments in the parse tree -- comment text and locations
are stored in a side-along array. The user has to re-associate the comments
with particular nodes after the fact. Fundamentally, comments are a
token-level feature, not a parse tree-level feature.
We sort of can do whatever we want with the parser API. Except for Esprima
compatibility for one. And also except that our parser doesn't track comments
at all, so we'd have to spend extra time and memory to record locations and
such, beyond what we do now. The side-along Esprima approach is probably the
only way this can work sensibly, given just how many places comments can be
put; I don't think any API we might have should attempt associations itself.
Jeff: Thank you for your willingness to explore solutions. I do want to
push back on the token/ast comment and bring what I think is a larger
problem to the attention of SM developers.
It's worth saying that Clang took a similar approach to separating
comments from the token and AST stream until they realized there was
considerable benefit to exposing comments in the AST (e.g. tools like
Doxygen wouldn't have to reinvent C/C++ parsing - a fool's errand IMO).
Python exposes docstrings in a __doc__ attribute of the function/class
they are associated with (unless in optimization mode, in which case
they are excluded for performance reasons). Python's AST also allows
access to attached docstrings [1].
Go's AST exposes associated documentation with nodes [2]. Go even has
APIs in the standard library for formatting documentation! I would go so
far as to say that Go's language services in the standard library [3]
are the gold standard for programming languages. You don't hear about Go
programmers tripping over themselves to write tools to parse and
manipulate Go source code because the facilities are provided for them
and they just work.
Rust provides language services for extracting and generating
documentation [4].
C# allows you to access documentation blocks via reflection. I believe
Java has a similar mechanism.
I guess what I'm trying to say is that SpiderMonkey/JavaScript appears
lacking in the "language services" arena. That's really unfortunate for
a language as powerful and ubiquitous as JavaScript. It's more
unfortunate for Mozilla and SpiderMonkey because any tools that people
do manage to conjure together typically struggle with SpiderMonkey
extensions or have difficulty keeping up with the rapidly evolving
JavaScript language, which Firefox JS typically takes early advantage
of. As has been stated previously in this thread, lack of good
documentation generation for SpiderMonkey JSMs is hurting Mozilla
because JS developers need to double document in source and on MDN. We
waste our time doing something that machines should be able to do with
little effort.
FWIW, this issue dovetails with us trying to minify chrome JS (bug
903149). One can argue that if we had access to robust JavaScript
language services (possibly including minifying) from the engine itself,
we wouldn't be stuck in a rut there either.
tl;dr we want robust JavaScript language services in the standard
library (or a SM-only extension) and we want them yesterday.
Any assistance on the SpiderMonkey and/or ECMAScript standardization
fronts would be appreciated. I don't follow SM development or ECMAScript
standardization closely: has this been discussed before?
[1] http://docs.python.org/2/library/ast.html#ast.get_docstring
[2] http://golang.org/pkg/go/ast/
[3] http://golang.org/pkg/go/
[4] https://github.com/mozilla/rust/tree/master/src/librustdoc
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
