Skip to content

Conversation

mikeyhew
Copy link

Q A
Bug fix? no
Breaking change? no
New feature? yes
Deprecations? no
Spec compliancy? yes (stage3)
Tests added and they pass? yes
Fixed tickets lightscript/lightscript#15
License MIT

So far this supports parsing -/*> and =/*>. There are two new tests, both of which only test parsing, and only for the named function syntax.

I didn't wrap the new parsing code in an if statement because I wasn't sure which plugin name to use. This file would suggest that it is asyncGenerators, is that correct?

@mikeyhew mikeyhew changed the title [WIP] Async iteration [WIP] Parse Async Generators Apr 25, 2017
Copy link

@rattrayalex rattrayalex left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work! One change request and a few additional tests that I imagine should be straightforward.

I can't remember, does anything else need to happen for this?

case "=*>": case "-*>":
node.generator = true;
break;
case "=/*>": case "-/*>":

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, could we do =*/> and -*/> instead? I prefer it visually and it's less likely to trip up syntax highlighters who think it's a comment. Unless there's a reason you prefer this style?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

=/*> is what came naturally to me, but sure, I can change it.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

return this.finishToken(tt.arrow, "-*>");
}

if (this.hasPlugin("asyncGenerators")) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice, this looks good!

@@ -0,0 +1,2 @@
fn() -/*>
yield await x

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these look good – let's also add the following tests:

f() =*/>
  yield <- g()
f() =*/>
  yield <!- g()
f() =*/>
  x = yield <- g()

These tests will also probably need to be copied into the plugin's test suite

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should also probably test that this raises a SyntaxError:

f() =*/>
  <- yield g()

If it doesn't do that by default, let's make it a friendly one 😄

@rattrayalex
Copy link

Hey @mikeyhew are you still interested in taking this over the finish line? I can help if not!

@rattrayalex
Copy link

(note that there are likely to be significant merge conflicts, which I can help you with as they're fairly straightforward)

@mikeyhew
Copy link
Author

mikeyhew commented May 4, 2017

@rattrayalex Sorry, I got sucked into Rust. (The programming language, not the game. 🙂 ) I'll see what I can get done tonight, and then after that I'll let you take over since I have school starting up again.

@mikeyhew mikeyhew force-pushed the async-iteration branch from af564cc to 05e34af Compare May 4, 2017 03:41
@mikeyhew
Copy link
Author

mikeyhew commented May 4, 2017

@rattrayalex I'll leave it for you to finish. I think I got the conflict sorted out. There's still those tests to add that you suggested; plus the tests that I wrote aren't passing anymore, and I didn't really understand the error message - "Did not expect a property 'delegate' (expression/0/body/body/0/body/program)".

I wanted to point out about the one negative test you suggested:

f() =*/>
  <- yield g()

You're allowed to have yield expressions inside await expressions - it just awaits the return value of the yield expression. But await yield g() seems to be a syntax error, I guess because await has higher precedence? Anyway, await (yield g()) is correct and parses fine.

@rattrayalex
Copy link

Awesome! I can take it from here then. The delegate thing is probably from the upgrade - removing the expected.json file and then re-running the test suite is probably the easiest way to fix it.

@rattrayalex rattrayalex merged commit 469d2d4 into lightscript:lightscript May 28, 2017
@rattrayalex
Copy link

@mikeyhew finally merged, sorry this took me so long to get to! Thanks for the contribution!

@mikeyhew
Copy link
Author

@rattrayalex no worries, thanks for finishing it up for me!

wcjohnson pushed a commit to wcjohnson/babylon-lightscript that referenced this pull request May 29, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants