Peer Input: Constructs of ECMAScript grammar

I’m working on a draft of this idea here and would sincerely appreciate peer input as I continue working towards an implementation and really appreciate your input (as I work very very hard to try to make it both read easier and more complete).

I’ve somewhat obsessively brought up this issue of parsing ECMAScript up in meetings at least one time (every meeting that is) as this seemed to be a very common aspect across module-related discussions, where at some point, you will need to safely and effectively deal with something in the source text.

ASTs are wonderful, and I am not making an argument against them in theory, and instead just consider uses where they are not practical to be of relative importance here.

Our discussions pointed me towards Tim Disney’s work, and it is impressive all around, but leaves one feeling a little out of depth trying to work with that theory and not feel like they are missing enough of the picture to risk missing enough of the picture that they cannot risk missing.

So I went ahead and started working on a way to reason about grammar so that abstractions like those introduced by Tim Disney feel somewhat intuitive, but also be able to cover as much of the ECMAScript grammar as needed to elicit the sense of confidence desired for the task.

Hi Saleh,

I guess I take our weekly meetings for granted, but I wanted to post here to acknowledge that your parser ideas are being carefully considered as an optimisation/simplification from the Babel-based parser we’re initially planning for the Realms Shim (

In discussion with you, I’ve pointed out that a very important property of the parser/rewriter is to be able to be strict and reject any input that could be malicious (i.e. parse one way but interpret a different way). Your Constructs idea definitely makes this possible, more than your original lenient parsing.

Let’s keep working towards this, and see how it can fit!

Thanks for your ideas,

1 Like