Parse eventual-send (tildot) syntax

[michaelfig]

Q	A
Fixed Issues?	Fixes #11348
Patch: Bug Fix?	No
Major: Breaking Change?	No
Minor: New Feature?	Yes
Tests Added + Pass?	Yes
Documentation PR Link
Any Dependency Changes?	No
License	MIT

This implements the parser changes described in #11348 to implement the stage1 TC39 eventual-send syntax proposal described in that issue.

I hope to land these changes soon, to experiment with plugins that use the tildot syntax. When the proposal is more mature, we will make a new PR to merge the appropriate plugins.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 0906e9f:

Sandbox	Source
competent-night-x48qw	Configuration
recursing-paper-rhir1	Configuration

[babel-bot]

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/23363/

[nicolo-ribaudo]

Is the difference between (a~.b).c and a~.b.c observable?

[michaelfig]

Is the difference between (a~.b).c and a~.b.c observable?

No, it is not.

[nicolo-ribaudo]

Ok, then we don't need the eventual: boolean property on EventualMemberExpression. For optional chaining, is needed to disambiguate between a?.b.c (two OptionalMemberExpressions, the inner one has optional: true and the outer one has optional: false) from (a?.b).c (one OptionalMemberExpression with optional: true, and one MemberExpression.

a~.b.c can be represented as an EventualMemberExpression and a MemberExpression.

Also, since this PR is quite big, can we keep the transform implementation for a separate PR 🙏

[michaelfig]

Ok, then we don't need the eventual: boolean property on EventualMemberExpression.

Thanks for catching this. I've updated accordingly.

Also, since this PR is quite big, can we keep the transform implementation for a separate PR 🙏

You bet!

[nicolo-ribaudo]

How does this proposal interact with optional chains? In a?.b~.c.d, are ~.c and .d accessed when a is nullish? Or is it equivalent to (a?.b)~.c.d? Is there an operator to do ?. and ~. at the same time (e.g. a?~.b)?

I think that this heavily affects the AST design.

Is the difference between (a~.b).c and a~.b.c observable?

I looked at the proposal's README, and realized that my question was incomplete. Since a~.b() and (a~.b)() are different (from what I understood, they are a.[[ApplyMethodSend]]('b', []) and a.[[GetSend]]('b')()), we would probably need a new EventualMemberCallExpression node if we go with the current AST design.

[nicolo-ribaudo]

(EDIT: Duplicated review comment)

[michaelfig]

I'll have to defer to @erights on these details.

How does this proposal interact with optional chains? In a?.b~.c.d, are ~.c and .d accessed when a is nullish? Or is it equivalent to (a?.b)~.c.d? Is there an operator to do ?. and ~. at the same time (e.g. a?~.b)?

I think that this heavily affects the AST design.

Agreed.

I looked at the proposal's README, and realized that my question was incomplete. Since a~.b() and (a~.b)() are different (from what I understood, they are a.[[ApplyMethodSend]]('b', []) and a.[[GetSend]]('b')()), we would probably need a new EventualMemberCallExpression node if we go with the current AST design.

I had been thinking that EventualMemberExpression and EventualCallExpression would be sufficient and that the equivalent of EventualMemberCallExpression could be introduced during the AST visitor after the parser is done. That may not be the case.

[JLHwung]

Updates: As @nicolo-ribaudo points out (a~.b)() is a~.b() is not equivalent. So adding eventual: boolean is not enough. I will post an updated suggestion tomorrow. I am still negative on adding new node types.

w.l.o.g. I will take EventualMemberExpression as an example, likewise EventualCallExpression.

I am hesitant about the extra node type EventualMemberExpression and likely-in-the-future EventualOptionalMemberExpression / OptionalEventualMemberExpression given that optional chaining has reached stage 4.

The wavy-dot proposal introduces infix operators ~. similar to optional chaining. I understand that it may seem reasonable to add a new node type, which is what we did in OptionalMemberExpression. Essentially OptionalMemberExpression is a MemberExpression. The introduction of the new node type OptionalMemberExpression is due to 1) the new optional semantic and 2) the short-circuit behaviour. The latter requires that a new node type has to be introduced because we need to know when the base is nullish, we should skip which parts of the whole optional chains.

EventualMemberExpression is also a MemberExpression. Similar to OptionalMemberExpression, it introduces new eventual semantics. Besides that I don't see there are extra behaviours which we should track on the AST level. Therefore I propose to add an eventual: boolean property to the existing MemberExpression

interface MemberExpression <: Expression, Pattern {
  type: "MemberExpression";
  object: Expression | Super;
  property: Expression;
  computed: boolean;
  eventual: boolean;
}

Since the eventual semantic is additive, we can also add eventual: boolean once the proposal supports optional chaining.

[michaelfig]

I think we still need EventualMemberCallExpression, which I would rename to EventualSendExpression. I'll wait on your updated suggestion before I start changing the current PR.

[michaelfig]

Also, just a note:

.?~ is sensible (only eventual-send if the lhs is not nullish), but .~? is not sensible (since eventual-send always returns a Promise, it cannot be nullish).

[michaelfig]

Updates: As @nicolo-ribaudo points out (a~.b)() is a~.b() is not equivalent. So adding eventual: boolean is not enough. I will post an updated suggestion tomorrow. I am still negative on adding new node types.

@JLHwung have you had a chance to think about this? I definitely want to implement the PR in the correct way, but am blocked until I get some design advice.

Thanks!

[JLHwung]

@michaelfig My approach is now based on the ChainingExpression approach proposed by ESLint team: See https://gist.github.com/JLHwung/6ec08a87e4da88874c50788c37d6fdf4 for detailed examples.

Note that this approach is tremendously different from current babel's approach and we will discuss if we will go for that path in the upcoming babel meetings. Before any decision is made, I would suggest we hold on a bit until more feedback from the AST shape of wavy-dot.

Updates: also open estree/estree#216 for AST discussion.

[michaelfig]

From the above, I found estree/estree#204 which is long, but seems to be giving some traction to https://gist.github.com/mysticatea/5453e721892b9c5a621e445f5fcdf62f

[michaelfig]

@michaelfig My approach is now based on the ChainingExpression approach proposed by ESLint team: See https://gist.github.com/JLHwung/6ec08a87e4da88874c50788c37d6fdf4 for detailed examples.

Note that this approach is tremendously different from current babel's approach and we will discuss if we will go for that path in the upcoming babel meetings. Before any decision is made, I would suggest we hold on a bit until more feedback from the AST shape of wavy-dot.

@JLHwung, has this discussion settled? If so, what does it mean for the kind of AST shape I should target?

[michaelfig]

@nicolo-ribaudo and @JLHwung, I'd like to see this PR move forward again. Would you be able to help me finish the AST design?

How does this proposal interact with optional chains?

Optional chains can short-circuit eventual sends.

In a?.b~.c.d, are ~.c and .d accessed when a is nullish?

They are short-circuited. a?.b~.c.d when a is nullish is just a.

Or is it equivalent to (a?.b)~.c.d?

(a?.b)~.c.d is implemented as (a?.b).[[GetSend]]('c').d which when a is nullish results in Promise.rejected(TypeError("Cannot read property 'c' of undefined")).d which is just undefined since promises usually don't have a d property.

Is there an operator to do ?. and ~. at the same time (e.g. a?~.b)?

Yes, we would like that. a?~.b would result in a if a is nullish, otherwise a~.b.

I looked at the proposal's README, and realized that my question was incomplete. Since a~.b() and (a~.b)() are different (from what I understood, they are a.[[ApplyMethodSend]]('b', []) and a.[[GetSend]]('b')())

That's correct.

we would probably need a new EventualMemberCallExpression node if we go with the current AST design.

That seems right to me.

[JLHwung]

Let's transfer the discussion about composition between optional chain and wavy-dot to the proposal repo. I think we have to hold off a bit until the draft clearly specifies the proposed syntax change to LeftHandSideExpression.

Because

this heavily affects the AST design

as @nicolo-ribaudo mentioned before.