Statements vs. Expressions

This isn't going to be explained satisfactorily by analogies or intuition, and it won't be logical at all, because it isn't, and you could define the grammar with no such distinction or a different set of distinctions as many posters already showed here.

Besides being arbitrary, I also never found this a useful distinction after having programmed in languages that don't distinguish this. And look at how GCC introduced ({...}) to convert back a statement into an expression.

Anyway, to define this, you have to simply list all the things: statements are 'return', '{...}', 'while() {... }', etc., while expressions are '5', 'f(...)', etc. That's it, that's the explanation. No intuition, just a comprehensive list taken from the grammar.

If course there is some rough idea behind it, which explains why there is a difference, but this is a history class, not an explanation: statements do some action, i.e., this is an imperative concept. Expressions have a value, i.e., this is a functional concept.

If the question is how they are different, then the answer is grammatically, and then the explanation of a grammar follows.

If it is why we make such distinction, then the answer is because the language creator decided so, followed by tradeoffs and pitfalls of making a specific language construct to have a value.

expression

- generally returns a value, possibly a void value, or doesn't return control at all.

- it consists out of operators, operands, and function calls

- can be composed out of one or more sub-expressions, and the order of their evaluation isn't always defined (i.e. to allow compiler optimizations).

- usually it doesn't have side-effects (i.e. pure), unless it uses random, time, IPC, system, or HW-specific pseudo-functions, pseudo-variables, or macros as a sub-expressions. Nested assignments and variable increments/decrements/etc. are also not pure.

- a result of a function call

statement

- usually an imperative command

- usually indicate a side-effect (e.g. assignment, sending a message, etc.)

- can be a procedure call or macro

- can be composed out of expressions and nested statements, but with better defined semantics / order of evaluation

- a special case: control flow statements

- a special case: "return" statement - evaluate a value and returns it as a result of the current function

That’s six expressions, not five. Josh conflates the the addition expression and the parenthesised expression, but they’re distinct (even if you couldn’t represent the semantics without the parenthesis due to operator precedence).

Here’s an approximate representation of the parse tree, indicating which nodes are expressions:

  MultiplicativeExpression {        ←
    ParenthesizedExpression {       ←
      AdditiveExpression {          ←
        DecimalIntegerLiteral("5")  ←
        "+"
        DecimalIntegerLiteral("1")  ←
      }
    }
    "*"
    DecimalIntegerLiteral("2")      ←
  }

Lisp was the first language I used (other than assembly code) so when I encountered C I was puzzled why they even bothered to have statements at all. 40 years later I still don't understand the point.

These are expressions:

https://github.com/estree/estree/blob/master/es5.md#expressi...

These are statements:

https://github.com/estree/estree/blob/master/es5.md#statemen...

I guess the confusing part for many is how an expression can also be a statement. But if you look at the ExpressionStatement you see that an expression is NOT also a statement. It's just the wrapper statement that makes it look so!

My understanding is this; Expressions return a value, statements on the other hand are actions, commands, definitions, declarations, assignments, and control structures.

`square = square(4)` is a statement (a definition to be exact) that associates name `square` with the value `square(4)`.

The name `square` itself, when later used, is an expression, because when you call it, it evaluates to a value `square(4)`.

What is sometimes confusing, is that some statements also double as expressions, that is, also return values; and that it also depends on the language. eg. the assignment statement returns a value in C and Javascript, but not in Go or Python;

    printf("%d\n", a = 42);
    // out: 42

    console.log(a = 42)
    // out: 42

    fmt.Printf("%d\n", a = 42)
    // out: syntax error: unexpected =, expecting comma or )

    print("%d" % a = 42)
    # out: SyntaxError: expression cannot contain assignment, perhaps you meant "=="?

    int main() {
        12 + 42;
    }

    12 + 42

    package main
    func main() {
        42
    }
    // ./main.go:3:5: 12 + 42 (untyped int constant 54) is not used

I may be wrong but I actually think the explanation can be a little simpler than the article posits: an expression (in JS) is something that returns a value. That's it. The value can be undefined/void, but it's still a value being returned.

One important detail the article seems to miss that I've come across whie explaining JS syntax to JSX-learners is that, while statements usually contain expressions, expressions can also contain statements. This is because a function definition returns a value (the function instance) & obviously function bodies can contain any JS syntax. This is useful if you (for some odd reason) want to embed a statement in some JSX code (since JSX only supports JS expressions).

I do think mandatory semicolons make the distinction a little easier. If it has a semicolon, it's probably a statement. And for most C-style languages if it has curly braces, it's probably a statement too. Otherwise it's an expression.

Really? With lit you can create a component that has several top-level elements[1].

EDIT: In fact this works even in react/preact with htm[2], so it's just a limitation of JSX.

[1]: https://lit.dev/playground/#project=W3sibmFtZSI6InNpbXBsZS1n...

[2]: https://github.com/developit/htm

But in the beginning it's hard for people to grok an expression with a couple of nested expressions in it. Especially if there's some functions calls in there as well.

Axel Rauschmayer has a good page (1) on this topic as well. Quite dry, so less beginner friendly.

So what I like about Josh W Comeau's article is that it's easy to read with lots of examples and even an interactive widget.

Oh and about interactive visualization of expression evaluation: Thonny (2) does this real nicely for Python code. Excellent for beginners imo.

[1] https://2ality.com/2012/09/expressions-vs-statements.html

[2] https://thonny.org/

  const MyComponent = () => {
    return (
      <>
        <h1>Hello world</h1> 
        { arr.map(val => <ListItem val={val} />) }
        <h1>Goodbye world</h1> 
      </>
    );
  }

In functions:

  const x = () => {

  };
  // or
  function myFunc() { 
  
  };

  if (x > 2) {
    return true;
  }

  while (x > 2) {
    doSomething();
  }

This is obviously part of the language grammar of many languages and makes it obvious why React uses curly braces as well for interpolating values.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

In fairness it's difficult to talk about statements accurately and succinctly without being more abstract - and perhaps the more general observation here is how explanation by example alone is not always sufficient. A more general and yet tangible starting point for statements in JS could be "anything ending in a semicolon" (not quite true but almost for normal code), which at least is better at highlighting it's breadth before piling into arbitrary examples.

With this definition, it's easy to see that, if the syntax starts with a language keyword, it's a statement.

BTW, language functions (like 'Array.join()') are expressions because they don't start with a keyword.

https://news.ycombinator.com/item?id=31944352

For example, functions that return functions:

const filter = (predicate, xs) => xs.filter(predicate)

So it's an assignment, leading me to think it's a statement, but then using filter later would be an expression?

    let x = <something>;

    <something>;