----- Original Message ----- > From: "Gregory Szorc" <[email protected]> > To: "Jeff Walden" <[email protected]>, > [email protected] > Sent: Tuesday, December 17, 2013 4:20:37 PM > Subject: Re: [JS-internals] Improvements to the Sphinx in-tree documentation > generation > > Thanks for the info Jeff. I'm not a language designer, so lots of my > examples were probably made in ignorance of how "language design works." > That being said, as an end-user of JavaScript, I find the lack of decent > "language services" very frustrating and the first people I look at are > the providers of the JS engines, because that's who in my mind is > responsible for them (e.g. Reflect.parse()) and who I have influence > over (courtesy of being a Mozillian). For SpiderMonkey, I naturally look > at the SM engine dev team. The ECMAScript standardization process is > largely invisible to me and I trust others to spend the time and > expertise to proxy opinions like mine to that body. I assumed someone on > this list could do that. But it sounds like I'm wrong? > > I'm not sure what else I need to do. I believe I've clearly articulated > that JavaScript's language tools pale in comparison to most other widely > used programming languages and I strongly believe this is holding > JavaScript back in ways. Is the next step then to take this to es-discuss?
I did some work on parsing and refactoring tools for C a long time ago. It's a pretty difficult problem because things like comments and macros aren't part of the language, but you still want to annotate them in the syntax tree somehow. What clang has managed to do is very impressive. That said, these sorts of systems are very finicky. They're usually based on lots of heuristics, and they take a lot of tuning before they produce decent results. For that reason, I don't think these sorts of tools belong in SpiderMonkey. It would be very difficult to standardize how they work, and then once the algorithm is standardized, we wouldn't be able to improve it. In addition, putting stuff in SpiderMonkey when it could be written in JS just adds to our attack surface needlessly. I think it makes a lot more sense for this sort of code to go in a parser like Esprima. I was just looking at Esprima, and it already does almost everything you need. Besides producing the big array of comments, it includes location information for the comments and for each parse node. A really simple tool could iterate over all the top-level declarations and see if there are any comments that start after the last declaration and before the next one. Then it could associate that comment with the next declaration. -Bill _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
