Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Operator precedence not respected #748

Open
kevin-dp opened this issue Feb 12, 2018 · 2 comments
Open

Operator precedence not respected #748

kevin-dp opened this issue Feb 12, 2018 · 2 comments

Comments

@kevin-dp
Copy link

I want to define an operator >>= which performs member access (i.e. is equivalent to .).

My first attempt does not compile:

operator >>= left 19 = (left, right) => {
    return #`${left}.${right}]`;
};

My second attempt (using computed member access) works but not as expected:

operator >>= left 19 = (left, right) => {
  let r = right.name.token.value; // string representation of an identifier
  let dummy = #`dummy`.get(0);
  return #`${left} [${fromStringLiteral(dummy, r)}]`;
};

I deliberately give my >>= operator precedence 19, which is the same precedence as javascript's member access operator (see JS operator precedence).

Based on the given precedence i would expect this to be possible:

var obj = {
    foo: function() {
        // return a promise
    }
};

obj>>=foo.then(res => { console.log(res); })

However, this does not compile. For some reason the right argument of my >>= operator is a call expression (i.e. foo.then(...)).

So, based on the given precedence i would expect obj>>=foo.then(...) to be equivalent to (obj>>=foo).then(...), however it seems to be interpreted as obj>>=(foo.then(...)).

If i manually add the parentheses as follows (obj>>=foo).then(...), then it works.

@disnet
Copy link
Member

disnet commented Feb 22, 2018

Yeah this is expected. All the forms that MDN calls precedence 19 (static/computed member access, new, call) are not really operators in the sense that Sweet understands. This is because they all have grammar restrictions that make them more specialized than a normal binary/unary operator and so expand "below" the level of Sweet's operator precedence rules.

@kevin-dp
Copy link
Author

kevin-dp commented Mar 3, 2018

Ok, that's a pitty.
But, why doesn't my first attempt compile, whereas my second attempt does?

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

No branches or pull requests

2 participants