-
Notifications
You must be signed in to change notification settings - Fork 157
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
question about import operator <<< #1080
Comments
I can imagine two possible reasonable compilations for a =
p1: 1
p2: 2
<<<
p3: a.p1 + a.p2
p4: 4 The first is a = { p1: 1, p2: 2, p3: a.p1 + a.p2, p4: 4 }; The second is (a = { p1: 1, p2: 2 }).p3 = a.p1 + a.p2;
a.p4 = 4; (This doesn't even address cases like As the current result of this compilation isn't equivalent to either of these, I'm calling this a bug, but I'm not sure which of my two possibilities should be the result instead. The precedence relation between |
Clearly it should be parsed this way..:) a =
p1: 1
p2: (2
<<<
p3: a.p1 + a.p2
p4: 4) |
Of course the second variant! Isn't it intuitive? The point is to reuse the name of newly created object and add properties that depend on the previous assignment. Your first example equals to this: a =
p1: 1
p2: 2
p3: a.p1 + a.p2
p4: 4 I used |
What do you think about this case: a = { p1: 1, p2: 2 } <<< p3: a.p1 + a.p2, p4: 4 Is that equivalent to the second variant or the first? f = -> p1: 1, p2: 2
a = f! <<< p3: a.p1, p4: 4 Or: f = -> p1: 1, p2: 2
g = -> p3: a.p1, p4: 4
a = f! <<< g! LiveScript currently interprets all of these as equivalent to the first variant, and I think that's probably correct. Do you agree? |
I think the question boils down to explaining why the following two snippets should be different (they currently are): a = x: 0
b = x: 1
a = b
<<< c: a.x
a.c #=> 0 a = x: 0
b = x: 1
a =
b
<<< c: a.x
a.c #=> 1 This duality exists with many other binary operators (at least, the ones that don't have a different interpretation when they start a line), such as Lines 317 to 319 in bc1c188
but that's a pretty clear indicator that this difference is intentional. This all favors @determin1st's preferred interpretation of his original submission; my only remaining unease is not being able to succinctly explain what the governing principle is here. It's not quite that a binary operator immediately following a dedent will take as its left operand the entire expression leading up to and including the indented block—counterexample: a <| b do
c
<<< d #=> equivalent to a(b(c) <<< d), not a(b(c)) <<< d Maybe a binary operator just gets a lower but non-zero precedence when it immediately follows a dedent—less binding than a do
b
^ c do
d
> e #=> equivalent to (a(b) ^ c(d)) > e
a do
b
> c do
d
^ e #=> equivalent to a(b) > (c(d) ^ e) Anyone have any good theories for me? |
your second example, be it a = f! <<< p3: a, p4: 4 currently means, that the value of variable a = 3
a = f! <<< p3: a, p4: 4 will do |
I'm afraid it does—it's very similar to the other example: f = -> p1: 1, p2: 2
g = -> p3: a.p1, p4: 4
a = p1: 0
a = (f! <<< g!)
a.p3 #=> 0
a = p1: 0
(a = f!) <<< g!
a.p3 #=> 1 |
well, your examples are tricky, but i feel, ill be okay with f = -> p1: 1, p2: 2
g = -> p3: a.p1, p4: 4
a = p1: 0
a = f! <<< g!
a.p3 #=> 1 |
should this code work?
because, this one works:
also, when used
import all
, it works:The text was updated successfully, but these errors were encountered: