Would it be possible to implement this as a babel plugin?

[samuelgoto]

Just kicking this off from a face to face chat I had with @hzoo.

This is currently prototyped/implemented as an acorn plugin but it brings all kinds of challenges. It would be great if this could be done as a babel plugin, but I wasn't sure if it would be feasible at all.

According to @hzoo it is possible. Kicking this thread off to get the ball rolling.

[xtuc]

Unfortunately Babylon cannot parse

a {
}

or

a(1) {
}

Making a Babel plugin would have an impact on our parser as well.

[ljharb]

@xtuc why not? The first one is an identifier and a BlockStatement, and the second one is a CallExpression and a BlockStatement. (That this is already valid syntax is one of the concerns voiced in TC39 with this proposal, in fact)

[xtuc]

@ljharb yes, that's right. I assumed that we wanted to make Babel plugin without modifying the parser (as you said the grammar).

The Acorn plugin is still easier to use for now.

[ljharb]

Right - I’m confused why we need to modify the parser. Block param syntax is already valid, it just doesn’t do what this proposal wants it to.

[xtuc]

"parse" is a bit misleading. Babylon can already tokenize the block param syntax since it's already valid but the rules in the grammar consider it invalid because of the current js spec.

We need to be able to understand the grammar to get an AST and create the transformation plugin.

[hzoo]

I think we're confusing the terms here? Since not everyone understands how it all works, yes we need to modify the parser and would have to make the same changes in babylon as acorn under a flag/babylon plugin. That's expected?

babel plugin, but I wasn't sure if it would be feasible at all.

Yeah we modify the parser and make a new babel plugin just like for another proposal such as numeric separators

[xtuc]

Yes, once it will reach the stage and some stability we'll create the corresponding Babel plugin (and change the parsing). I didn't mean it's not feasible.

[samuelgoto]

Yeah we modify the parser and make a new babel plugin just like for another proposal such as numeric separators

FWIW, here is a really crappy implementation with an acorn plugin:

https://github.com/samuelgoto/proposal-block-params/blob/master/docscript.js#L18

Yes, once it will reach the stage and some stability we'll create the corresponding Babel plugin (and change the parsing). I didn't mean it's not feasible.

I'd hold on a little bit more until it gets into further stages before doing anything ... lots of really hard open questions to push through before this needs any extra feedback from implementations ...

[samuelgoto]

Right - I’m confused why we need to modify the parser. Block param syntax is already valid, it just doesn’t do what this proposal wants it to.

Hummm are you sure that's the case? These throw SyntaxErrors to me:

function a() {}
> undefined

a {
}
> Uncaught SyntaxError: Unexpected token {

a() {
}
> VM110:1 Uncaught SyntaxError: Unexpected token {

What am I missing?

[ljharb]

ah, you're right; it'd have to be a newline to be valid as-is.

[xtuc]

ah, you're right; it'd have to be a newline to be valid as-is.

Now i'm confused, does that parse in Chrome?

My point was that the tokens are correct but the construction/grammar is not.

[samuelgoto]

Now i'm confused, does that parse in Chrome?

Nope. That does not parse in chrome WITHOUT the newline between a and {. Hence, it requires a parser change, i.e. this is new syntax.

[xtuc]

Ok, that make sense because it adds a ; between a and { (I believe JS has ASI?).