-
Notifications
You must be signed in to change notification settings - Fork 29
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
Binary operators starting on new lines #1121
Comments
Related #1280 |
I notice that the same issue occurs without extra.split(/\s+/).filter x
++ [state.start, state.goal] The real issue is that we handle binary operators that start on the next line, and then there's a question of which expression to attach that to. I guess our intuition is that the implicit function call (on |
Inspired by the bulleted arrays PR (#1361), I have an idea for how to address this: when entering filter foo
+ rest
↓↓↓
filter(foo)
+ rest
// but
filter foo
+ rest
↓↓↓
filter(foo
+ rest) The bad news is that chaining multiple implicit function calls on the same line would require additional indentation, like so: f1 f2 f3 f4 f5 x
+ y
// ^needs 5 spaces because 5 function calls I don't think that's good, but I'm also not quite sure how to fix it. Maybe instead of increasing the indentation by 1, we add a boolean flag to the indentation saying "> i" where i is the current indentation, instead of the usual meaning of ">= i". And then we won't repeatedly add 1; instead we just repeatedly change the flag to ">" which has no effect beyond the first. Not the simplest solution, but maybe workable... Let me know if you have better ideas! |
I reviewed this idea some more, and realize that we have almost this exact functionality, via extra.split(/\s+/).filter &
++ [state.start, state.goal] extra.split(/\s+/).filter &
++ [state.start, state.goal] parse as extra
.split(/\s+/)
.filter(($) => $)
.concat([state.start, state.goal]); And no existing tests fail. The question is whether we want this behavior, or whether we'd like the latter example to bring the switch x
> 0 // condition, not x > 0 So if we want these to parse differently, we could add I tried looking at how postfix accesses behave for comparison. This one makes sense: extra.split(/\s+/).filter &
.sort()
---
extra
.split(/\s+/)
.filter(($) => $)
.sort(); But this one does not: extra.split(/\s+/).filter &
.sort()
---
($) => extra.split(/\s+/).filter & $.sort(); Presumably that's a bug, though, and |
I think this is a bug:
Expected compilation:
Actual compilation:
The text was updated successfully, but these errors were encountered: