I was going to create a new issue about disabling ...

# javascript

[Edoardo Luppi]

I was going to create a new issue about disabling syntax validation for js(...) calls, until I read the actual code that parses it.
Basically K/JS hosts a copy of the old forked GWT Rhino parser, which coincidentally hasn't been updated in 10 years under GWT itself.

That means supporting new ES standards isn't as straightforward as I thought: to support coroutines as JS generators the copied Rhino parser had to be refactored.
So the question is, why is Kotlin still using an old version of Rhino, instead of bringing in Rhino as a standalone dependency, or repackaging it from Mozilla?

[Artem Kobzar]

As far as I remember, we are translating it to our own JS AST (to not convert Rhino AST to our), but I'm not sure. When I came it was already there.

[Artem Kobzar]

@bashor could know better

[Edoardo Luppi]

Thanks @Artem Kobzar. Asked because it feels like you're gonna have to do (again) the work of Mozilla devs to support those new ES features, which will be probably be more and more commonly used in the future.

Take for example the exponentiation ** operator, which has been worked around using a Function call, but which might not be desirable as it's a form of runtime evaluation.

[bashor]

There was an idea to stop embedding/converting a code passed to the js function to our internal representation. Of course, current behavior (with embedding) has some benefits, but it complicates some other things. After such a split we could either stop parsing a code passed to js fun or use any parser to verify correctness.

It might be a breaking change and should be done carefully.

[Edoardo Luppi]

@bashor having an internal parser might be useful if it means it can be used to optimize the outputted JS AST. Otherwise to me it seems unnecessary.

To be honest, the js("...") docs don't even mention validation, most people think they can pass whatever to it.

[Edoardo Luppi]

@janvladimirmostert here you go.