6 ms·

VB's evaluation order, in which the left side of an assignment is evaluated before the right side, seems like a terrible idea. In most languages including C and

by tlb 8y ago

VB's evaluation order, in which the left side of an assignment is evaluated before the right side, seems like a terrible idea. In most languages including C and C++, it's specified that the RHS is evaluated first. Since, of course, the RHS might have a side effect on the location of the LHS. Is there some advantage to LHS-first that I can't think of?

userbinator 8y ago
including C and C++, it's specified that the RHS is evaluated first. I did not check C++ but for C, according to ISO/IEC 9899:1999 section 6.5.16 paragraph 4 on the semantics of the assignment operator: "The order of evaluation of the operands is unspecified."
- tlb 8y ago
  Gosh, you're right. Clang warns, at least: t-order.c:10:8: warning: unsequenced modification and access to 'x' [-Wunsequenced] foo[x++] = x;
  - ngcc_hk 8y ago
    Language that is complicated in syntax also ended up with discussion like that. A couple of day ago you have the VisiCalc guy talked about he need to do a stack machine against the expectation here. Think of lisp But then lisp require parentheses Think of j but the strange right hand side then fork/train. It is hard for this simple thing. Even = and =: get Python dictator for life resigned. Just hard
eropple 8y ago
Just guessing, but perhaps it's more intuitive to non-programmers/casual users? You read left-to-right.
- MagicPropmaker 8y ago
  אני לא קורא משמאל לימין
  - chrismorgan 8y ago
    Not closely related, but this made me think of another fascinating aspect of localisation. In places like Australia and America, if you have a group of people and you’re going round them (e.g. reading in turns or playing various card games), you’d be more likely to go clockwise from on top rather than counter-clockwise. But in India, they naturally go counter-clockwise from on top rather than clockwise, and I once saw someone playing a game of hearts on a phone there, and it was going counter-clockwise. Localisation definitely entails more than just translating strings. Layout and functionality changes can be involved.
    - marton78 8y ago
      In my native Hungary we also play counter clockwise, so I looked it up[1]: Dealing is done either clockwise or counterclockwise. If this is omitted from the rules, then it should be assumed to be: * clockwise for games from North America, North and West Europe and Russia; * counterclockwise for South and East Europe and Asia, also for Swiss games and all Tarot games. [1] https://www.pagat.com/mech.html https://www.pagat.com/mech.html
  - ygra 8y ago
    In Latin script you do. Most programming languages I know are not in Hebrew. And even then the LHS would be first in reading order, I'd assume.
  - sho 8y ago
    Oh yes you do, or you couldn't even use this site, let alone do any programming. For better or worse left-to-right has "won" in programming-land and I fully agree with alangpierce that it's the natural choice for evaluation order as well. We read left-to-right and the computer should as well. That's one of the main problems I have with Python. Evaluating right-to-left just feels like being contrarian.
alangpierce 8y ago
Interesting, my intuition is the opposite: that left-to-right evaluation is clearly the better approach. I just tested a few languages and it turns out that there's no clear agreed-upon answer, but LHS first seems to be more common at least for recent languages: LHS first: JavaScript, Java, Go, C#, Swift, PHP, Ruby RHS first: C++, Python, Rust I ran this sort of code for all of them: def lhs(): print "LHS"; return 0 def rhs(): print "RHS"; return 0 a = [0] a[lhs()] = rhs() "=" is syntactically just a binary operator, so I expect it to behave like other binary operators (and AFAIK all other binary operators evaluate left-to-right in almost all languages). It's special because the LHS evaluates to an assignable reference rather than to a value, but nothing stops you from evaluating the left side in full before starting to evaluate the right side. As with every binary operator, it's possible to write code such that the evaluation of one side affects the result of evaluating the other side, but of course that sort of code is really fragile anyway.
- bArray 8y ago
  And this is why I tend to use a slightly smaller subset of some of the features that C-family languages support, along with an abundance of brackets. If I remember rightly, there is the example: a = {-1, -1} x = 0 a[++x] = x print(a[0] + " " + a[1]) Depending on the language (and sometimes even if you have optimizations set for those that compile to binaries), you'll get a different answer. I always love (read sarcasm) to see awesome code, such as: z = a & b > c | d or: z = a > b ? c < d ? e : f : g ? h : i And then of course, the statement: "my code doesn't need comments because the code comments itself"...
  - lern_too_spel 8y ago
    Don't do that. The behavior is explicitly undefined in C. http://c-faq.com/expr/seqpoints.html http://c-faq.com/expr/seqpoints.html
    - oblio 8y ago
      Don't do what, precisely? He listed several examples. And I think he's agreeing with you, he's just sarcastic.
minitech 8y ago
> Since, of course, the RHS might have a side effect on the location of the LHS. That’s a reason it matters which one is evaluated first, but not a reason to evaluate the RHS first.
kodablah 8y ago
In some languages like Go that support multi assignment, evaluation of some parts of the LHS occur first to help with pointer indirection and index clause evaluation [0][1]. I assume this makes the multi assign predictable because the locations of the LHS are known before the RHS is started. 0 - https://golang.org/ref/spec#Assignments https://golang.org/ref/spec#Assignments 1 - https://golang.org/ref/spec#Order_of_evaluation https://golang.org/ref/spec#Order_of_evaluation
rienbdj 8y ago
Better to avoid computations on the Lhs entirely!
int_19h 8y ago
Evaluating expressions left-to-right is a simple rule that can be universally applied, and produces predictable results. The problem here, in any case, isn't the order of evaluation. It's that the array bound check is done at the wrong time.
beobab 8y ago
I seem to remember my university lecturer (way back in '96) demonstrating that rightmost evaluation could lead to "variable capture", but that "leftmost-outermost" evaluation would always avoid that problem. It's been a while, however, so I might be remembering wrong (or indeed have misunderstood).

by tlb 8y ago

userbinator 8y ago

including C and C++, it's specified that the RHS is evaluated first. I did not check C++ but for C, according to ISO/IEC 9899:1999 section 6.5.16 paragraph 4 on the semantics of the assignment operator: "The order of evaluation of the operands is unspecified."

tlb 8y ago
Gosh, you're right. Clang warns, at least: t-order.c:10:8: warning: unsequenced modification and access to 'x' [-Wunsequenced] foo[x++] = x;
- ngcc_hk 8y ago
  Language that is complicated in syntax also ended up with discussion like that. A couple of day ago you have the VisiCalc guy talked about he need to do a stack machine against the expectation here. Think of lisp But then lisp require parentheses Think of j but the strange right hand side then fork/train. It is hard for this simple thing. Even = and =: get Python dictator for life resigned. Just hard

eropple 8y ago

Just guessing, but perhaps it's more intuitive to non-programmers/casual users? You read left-to-right.

MagicPropmaker 8y ago
אני לא קורא משמאל לימין
- chrismorgan 8y ago
  Not closely related, but this made me think of another fascinating aspect of localisation. In places like Australia and America, if you have a group of people and you’re going round them (e.g. reading in turns or playing various card games), you’d be more likely to go clockwise from on top rather than counter-clockwise. But in India, they naturally go counter-clockwise from on top rather than clockwise, and I once saw someone playing a game of hearts on a phone there, and it was going counter-clockwise. Localisation definitely entails more than just translating strings. Layout and functionality changes can be involved.
  - marton78 8y ago
    In my native Hungary we also play counter clockwise, so I looked it up[1]: Dealing is done either clockwise or counterclockwise. If this is omitted from the rules, then it should be assumed to be: * clockwise for games from North America, North and West Europe and Russia; * counterclockwise for South and East Europe and Asia, also for Swiss games and all Tarot games. [1] https://www.pagat.com/mech.html https://www.pagat.com/mech.html
- ygra 8y ago
  In Latin script you do. Most programming languages I know are not in Hebrew. And even then the LHS would be first in reading order, I'd assume.
- sho 8y ago
  Oh yes you do, or you couldn't even use this site, let alone do any programming. For better or worse left-to-right has "won" in programming-land and I fully agree with alangpierce that it's the natural choice for evaluation order as well. We read left-to-right and the computer should as well. That's one of the main problems I have with Python. Evaluating right-to-left just feels like being contrarian.

alangpierce 8y ago

Interesting, my intuition is the opposite: that left-to-right evaluation is clearly the better approach. I just tested a few languages and it turns out that there's no clear agreed-upon answer, but LHS first seems to be more common at least for recent languages: LHS first: JavaScript, Java, Go, C#, Swift, PHP, Ruby RHS first: C++, Python, Rust I ran this sort of code for all of them: def lhs(): print "LHS"; return 0 def rhs(): print "RHS"; return 0 a = [0] a[lhs()] = rhs() "=" is syntactically just a binary operator, so I expect it to behave like other binary operators (and AFAIK all other binary operators evaluate left-to-right in almost all languages). It's special because the LHS evaluates to an assignable reference rather than to a value, but nothing stops you from evaluating the left side in full before starting to evaluate the right side. As with every binary operator, it's possible to write code such that the evaluation of one side affects the result of evaluating the other side, but of course that sort of code is really fragile anyway.

bArray 8y ago
And this is why I tend to use a slightly smaller subset of some of the features that C-family languages support, along with an abundance of brackets. If I remember rightly, there is the example: a = {-1, -1} x = 0 a[++x] = x print(a[0] + " " + a[1]) Depending on the language (and sometimes even if you have optimizations set for those that compile to binaries), you'll get a different answer. I always love (read sarcasm) to see awesome code, such as: z = a & b > c | d or: z = a > b ? c < d ? e : f : g ? h : i And then of course, the statement: "my code doesn't need comments because the code comments itself"...
- lern_too_spel 8y ago
  Don't do that. The behavior is explicitly undefined in C. http://c-faq.com/expr/seqpoints.html http://c-faq.com/expr/seqpoints.html
  - oblio 8y ago
    Don't do what, precisely? He listed several examples. And I think he's agreeing with you, he's just sarcastic.

minitech 8y ago

> Since, of course, the RHS might have a side effect on the location of the LHS. That’s a reason it matters which one is evaluated first, but not a reason to evaluate the RHS first.

kodablah 8y ago

In some languages like Go that support multi assignment, evaluation of some parts of the LHS occur first to help with pointer indirection and index clause evaluation [0][1]. I assume this makes the multi assign predictable because the locations of the LHS are known before the RHS is started. 0 - https://golang.org/ref/spec#Assignments https://golang.org/ref/spec#Assignments 1 - https://golang.org/ref/spec#Order_of_evaluation https://golang.org/ref/spec#Order_of_evaluation

rienbdj 8y ago

Better to avoid computations on the Lhs entirely!

int_19h 8y ago

Evaluating expressions left-to-right is a simple rule that can be universally applied, and produces predictable results. The problem here, in any case, isn't the order of evaluation. It's that the array bound check is done at the wrong time.

beobab 8y ago

I seem to remember my university lecturer (way back in '96) demonstrating that rightmost evaluation could lead to "variable capture", but that "leftmost-outermost" evaluation would always avoid that problem. It's been a while, however, so I might be remembering wrong (or indeed have misunderstood).