Hacker News Reader

Comment by tlb | Hacker News Reader

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?

View on HN

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.

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"...

Don't do that. The behavior is explicitly undefined in C. http://c-faq.com/expr/seqpoints.html

Don't do what, precisely? He listed several examples.

And I think he's agreeing with you, he's just sarcastic.

He said, "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."

C does not support his first example. The standard states that the behavior is undefined.

> If I remember rightly [..]

You're probably not wrong, but I specifically remember there was something you could do in order to trick the compiler to allow modification on the left hand side to happen. It could possibly be by having two variable names referencing the same variable - for example.

Besides, the whole point was that it's usually not clever "trying to be clever". It just creates confusion. I don't personally believe the majority of people need to test the entire C spec to it's absolute boundary. A subset serves most people perfectly well.

I've recently started working on a code base with great comments and they are worth their weight in gold. Especially class and method level description comments. And doubly especially the class level ones.

Also there is none of the code golf in there that you have just given as an example.

> z = a > b ? c < d ? e : f : g ? h : i

That's stylistically ugly but not hard to predict; at some point I had it beaten into my head that ternaries are always at the bottom of the single-character operator precedence stack (I really hope all languages stick to that). I'd expect most people to know this.

> z = a & b > c | d

That is harder to predict. I wouldn't expect most people to know this one without looking up a precedence list.

It gets better when you compile that C code as C++, as ?: has a different precedence level.

Is there no language in which evaluation order is random/undefined?

Scheme doesn't define an evaluation order.

As mentioned elsewhere, it's unspecified in C but tends to be right-to-left in practice. To be clear, my categorization of languages is just from testing it directly, I didn't look it up in the spec for any of them. But I think newer languages try to have fully-defined behavior, at least for things like this.

RHS seems right to me because it means the actions on the LHS happen consecutively.

To expand your example a bit:

  class ShoutyContainer:
      def __setitem__(self, index, value):
          print("Assignment")
  
  def lhs(): print("LHS")
  def rhs(): print("RHS")
  a = ShoutyContainer()
  a[lhs()] = rhs()

Yields:

  RHS
  LHS
  Assignment

If LHS were evaluated first, then it would be separated from the final assignment step by the RHS evaluation. That would be odd.

I think it depends on how you think about it. As mentioned elsewhere, "=" is a special statement syntax rather than an operator in Python, but if you were to think of it like an operator, it would be evaluated in three phases: (1) evaluate one side, (2) evaluate the other side, (3) perform operation. The __setitem__ method defines how the left side participates in step 3, but IMO there's a separate LHS evaluation step that's independent of the assignment itself.

You might call this code snippet analogous:

    class ShoutyNumber:
        def __init__(self, n):
            self.n = n
            print(f'Created {self.n}')
    
        def __add__(self, other):
            print(f'Added with {self.n}')
            return self.n + other.n
    
    ShoutyNumber(1) + ShoutyNumber(2)

Yields:

    Created 1
    Created 2
    Added with 1

But I understand that in some mental models and some implementations, it's cleaner to have the entire RHS value ready before starting any evaluation of the LHS. I think that avoids the need to have "assignable reference" as a special type of expression result.

In Python `=` is not just a binary operator. Python is evaluated left-to-right (but not on assignment).

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."

Gosh, you're right. Clang warns, at least:

  t-order.c:10:8: warning: unsequenced modification and access to 'x' [-Wunsequenced]
    foo[x++] = x;

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

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.

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 1 - https://golang.org/ref/spec#Order_of_evaluation

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

אני לא קורא משמאל לימין

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.

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

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.

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.

> 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.

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).

Better to avoid computations on the Lhs entirely!

Reply on news.ycombinator.com