claus.reinke at talk21.com
Wed Jul 6 13:27:39 PDT 2011
> I don't think we have any consensus within TC39 WRT
> whether such an API should be part of some future version
> Ecma-262. Personally, this sounds like library functionality
> that in the future might manifest as a module. I think we
> need to draw a line at adding very many more such libraries
> to the core standard. For things like this it is too hard to
> specify them and not clear that there is a single preferred solution.
Ah, sorry. Seems I got the wrong impression from the list
archives - perhaps only the interested parties participated in
those older threads. Thanks for clarifying.
Anyway, even for a library version, there needs to be an API.
And since there are multiple JS parsers, and JS parser users,
it would be helpful if they could agree on a standard AST.
Which brings us back to the topic, independent of whether
or not browser vendors choose to expose their ASTs.
> Everybody would like their favorite library to be "built-in"
> so there is no loading cost. But there are a huge number of
> potentially useful libraries and only a few are ever going to
> get built-in.
If this was something you still needed to build in, I wouldn't
argue for it. The point is that the JS parser is already in there.
I can even call it from JS, via 'eval', in any JS implementation.
I just can't get my hands on the intermediate AST yet!-)
>From recent messages, it seems that the general opinion is
actually against a standard parser API, which is surprising.
In as much as this due to technical reasons (efficiency
concerns, too large a gap between internal representation
and useful external API), could this be reflected on the
strawman page, please?
Just so no-one else gets unreasonably optimistic.
> really the highest priority on the list? What percentage of
> web applications need to parse JS code?
If some startups get their wishes, some JS development
might move into the browser (browser-based editors and
IDEs, storage in the cloud). All developers using those
tools would depend on browser-based JS parsing. Even
in bog-standard development today, debuggers and
profilers could profit from parsing and instrumenting
code (building such tools in JS instead of hooking into
lower-level browser APIs).
And JS has long ceased to be only about web applications
or browsers. Once JS engines have commandline interfaces,
or socket interfaces, they are accessible wherever any JS tool
development is taking place. So why shouldn't they offer their
tools for JS in JS?
Yes, JS should be fast enough to support JS-based parsers,
and for playing with extended JS, or with non-standard
parser features, there is no way around that. But why have
two standard parsers when the built-in one will do the job?
But as Oliver has pointed out, the built-in one might not
be able to do the job after all.
More information about the es-discuss