Statements vs. Expressions

https://www.joshwcomeau.com/javascript/statements-vs-expressions/

by kretaceous • 4 years ago

63 82 4 years ago

wruza2• 4 years ago

No intent to sound negative, but doesn’t explanation by numerous cues mud the water even more? I bet most of students are left confused with this “wrapper statement” thing. Magical thinking induced.

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.

epolanski2• 4 years ago

I feel the same towards the article, I think that the moment you need to resort to "think of it as..." it's the moment you lose me.

I also don't think he does a good job at explaining the biggest source of misunderstanding. Quoting the article:

`Expressions and statements are distinct things.`

That is not really correct.

A function call, e.g. is both an expression and a statement:

`foo(bar)` on it's own is both an expression (it returns a value, even if the value returned is undefined) and a statement.

In fact, determining if a piece of code is an expression or a statement in all borderline cases depends on the context.

```

const foo = function bar(){};

function bar(){}

```

On line 1 the bar function is an expression, on bar 3, is a statement.

There's nothing really about the function on it's own that can tell you whether it is an expression or a statement.

On the other hand, a nice way to differentiate statements from expressions is that you cannot use statements where you need expressions.

```

console.log(if (3 > 2) {})

const foo = while (i < 3) {} ```

both lines are syntax errors.

azangru• 4 years ago

I've never read the ECMAScript spec; but searching through it, I can see that the terms they use is function declaration vs function expression. According to their terminology, function bar(){} on the second line of your function example is a function declaration.

dtagames4• 4 years ago

The way I think of it is that statements involve keywords from the language (like 'let', 'export class', or 'if') while expressions do not.

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.

Measter• 4 years ago

But that logic falls apart with languages such as Rust, where a lot of expressions start with a keyword.

dtagames4• 4 years ago

Ah. Was just thinking of JS/TS in this case. Good point.

simiones2• 4 years ago

That doesn't really work, since `alert("Hello, World!")` or `doSomething()` are usually statements, not expressions; while `new SomeFunction()` is usually an expression, as is `'abc' in ['abc']`

I think that, in the context of JavaScript, if you want a "quick and dirty" way to differentiate them, the `console.log( /* put thing here */ ) ` idea from the article is the best way to go - if you can validly put the thing there, it's an expression, otherwise it's a statement.

mxben3• 4 years ago

`alert("hello")` is an expression and also a statement.

  a = alert("hello"); // Assigns a to undefined

What isn't an expression? An `if` statement is not an expression.

  a = if (true) alert("hello"); // Uncaught SyntaxError: Unexpected token 'if'

ufo• 4 years ago

There is some historical precedent for what you said. The first programming languages were assembly languages, which only have statements that you write one per line. You can sort of say that each instruction name is a "keyword".

    mov eax ebx
    jump 1235
    xor eax eax

The first big programming language with expressions was Fortran. Its expressions were for mathematical formulas. Everything else was a statement that you still had to write one per line (and in under 80 columns, to fit in a punch card).

Part of the reason fortran was like this is that parsing algorithms were quite primitive. Ideas such as lexing, "tokens", and context-freem grammars, which are standard today, weren't common back then. For example both of the following were valid ways to start a loop in Fortran. Note the lack of whitespace in the second!

    do i = 1, 10
    doi = 1,10

Moving on, as compiler writers got better at parsing it became more popular to allow free formatting in programming languages. Instead of mandating one statement per line, use semicolons as statement terminators and let you format it as you see fit. Over time this led to a blurrying of the distinction between statement and expression. For example, in C and Javascript many things that used to be statements are now expressions (one notable example being assignments). This is taken the furthest in functional programming languages, where almost everything is an expression.

dtagames4• 4 years ago

Yes! Maybe I think of it this way because I'm over 50. I originally worked on System/370 assembler and Fortran at IBM.

goto112• 4 years ago

JavaScript have operators which are keywords, e.g. instanceof and void. "void(2 + 2)" is a valid expression

bluepnume2• 4 years ago

If this compiles, <something> is an expression:

    let x = <something>;

If this compiles, <something> is a statement:

    <something>;

Both, either, or neither can be true.

FeepingCreature7• 4 years ago

So 'if', 'for', 'while' are not statements?

teddyh• 4 years ago

No. Those are syntactic elements.

lmm4• 4 years ago

Not on their own. A full if, for or while (with the conditions and body) is usally a statement, and might be an expression in some languages.

shikoba2• 4 years ago

In JavaScript no. But in some languages it can be.

hibbelig3• 4 years ago

I can't think of an example where

    let x = <something>;

compiles but

    <something>;

does not compile. I think all expressions are statements.

lmm4• 4 years ago

Some languages forbid "obviously pure" expressions like "0" as statements (since using them as a statement is probably a mistake).

bluepnume2• 4 years ago

Right. They're not mutually exclusive -- hence the "both, either, or neither"

FeepingCreature7• 4 years ago

Statements are orders, expressions are questions.

shikoba2• 4 years ago

The answer to a question to be precise.

nivertech3• 4 years ago

The answer to a question to be precise.

No. The expression before evaluation (i.e. as it's written) is a question/query/ask, after a successful evaluation you get a value - an answer. In case when the evaluation failed, you get either a compilation/parsing error, runtime error/exception, crash, infinite loop/no return, or undefined behavior.

- Commands and Queries (as in CQS[1] and CQRS[2])

- Wishes and Asks (it's a wish b/c unlike command it can be rejected, and for the same reason it's an ask and not a query - i.e. "you may ask, but it doesn't mean I'll answer").

- Truth or dare?[3] (Dares and Truth-es ;)

[1] https://en.wikipedia.org/wiki/Command%E2%80%93query_separati...

[2] https://martinfowler.com/bliki/CQRS.html

[3] https://en.wikipedia.org/wiki/Truth_or_dare%3F

SeanLuke2• 4 years ago

Ask yourself why Lisp has no statements. Is it impossible to issue orders to the Lisp runtime?

FeepingCreature7• 4 years ago

Lisp does have statements, such as `setf` or `loop`. Just because you also attach an expression to it because hey, gotta evaluate to something, doesn't mean it's not fundamentally a statement.

Sure, syntactically it's an expression-based language, but some of those are expressions in syntax only. If a function terminates in nil, what exactly did it compute? And what exactly is the point of all but the last argument to a `progn`?

An expression that is evaluated for the side effects, not the result value, is a statement in every way that matters.

(Haskell has a stronger claim because it actually captures the side effects as a value.)

niels_bom• 4 years ago

As a programming teacher I think this is quite a fundamental thing to learn for new programmers. Even though lots of tutorials and books don't mention this explicitly people usually get an intuition for the difference after a while.

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/

submeta• 4 years ago

The article left me more confused than enlightened.

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

nivertech3• 4 years ago

Not a JS-specific answer to this question:

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

chrismorgan2• 4 years ago

statement
- a special case: control flow statements

But it’s worth noting that this is not true in all languages: in some languages, almost everything or actually everything is an expression. In Rust, for example, control flow things may be statements or expressions (a mildly fuzzy distinction, but it comes down to whether it produces a value other than (), and whether it needs a semicolon after the closing curly brace), and some control flow things are very useful as expressions:

  let a = if b {
      c
  } else {
      d
  };

  let e = loop {
      break f;  // f is a value, not a label (which uses lifetime syntax, 'g).
  };

nivertech3• 4 years ago

Ternary operator is an expression, first implemented as COND in Lisp.

In some cases it can be optimized to remove branching, especially when vectorized for SIMD/SIMT.

  int a,b,c,d;
  a = b ? c : d;

  // optimized to something like this:
  a = b*c + (1-b)*d

In some PLs even loop statements can produce values (CoffeeScript, Autocode), i.e. similar to list comprehensions, which are undoubtedly expressions.

I'm a kdb+/q developer, and most of the q code are expressions without conventional control flow operators (the only place they're used is outside of the main path: i.e. logging, testing, etc.).

IMO control flow (i.e. actual branching and looping) is just an implementation detail.

usrbinbash• 4 years ago

I think the simplest explanation is; "An expression can be used where a value is expected".

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 "=="?

Also depending on the language, expressions themselves may be valid statements. For example, this compiles in C;

    int main() {
        12 + 42;
    }

;this is a valid python program:

    12 + 42

;but if I try this in Go:

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

bluetomcat• 4 years ago

Generally, an expression returns a value and can be used as the operand of an operator, whereas a "statement" is the terminal "top-level" node that doesn't return a value and cannot therefore be nested.

oxff• 4 years ago

Expressions `yield` values, statements don't yield values.

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

amadeuspagel4• 4 years ago

For example, you might have tried writing something like this:

  foo = if (x < y) {
    ...
    ...
  }

Doesn't work because statements don't yield values.

Akronymus• 4 years ago

Thats one of the reason why I REALLY like languages where everything is an expression.

    let foo = 
        if x < y 
            somevalue
        else
            someothervalue

in f# for example.

bern44443• 4 years ago

So are ternaries expressions then too?

  const x = x < y ? 2 : 3;

daralthus• 4 years ago

I would like to see a programming language where there is no distinction between the two. This might sound silly first, but once you start thinking about homoiconicity or about function approximations, like neural nets that can represent any function (as sort of a compressed lookup table) then you can start to imagine how a sufficiently advanced compiler should be able to inline approximate representations, or switch to calculating on the fly depending on needs and available resources.

amadeuspagel4• 4 years ago

Lisp?

wruza2• 4 years ago

Not sure if it was irony, but check out Haskell and alikes. Its execution model is different from a regular “it evaluates at where it is”. Infinite lists like all natural numbers are a norm in it.

  ones = 1 : ones
  take 3 ones // [1,1,1]

  odds = 1 : map (+2) odds
  take 3 odds // [1,3,5]

Haskell has a statement-like “do” notation, but it is a syntactic sugar for a structure of specific operators.

Lisp is also a beast to be aware of, though it is not exactly what you described.

remkop22• 4 years ago

Rust actually accomplishes this with the unit '()' type which is similar but not the same as void in other languages. Any statement (or expression) produces a value, sometimes that value is just a unit, which can be passed around just as any other value. Currently the exception to this are 'let' statements but there is a nightly feature where this produces a unit value as well.

amadeuspagel4• 4 years ago

I think we often blame React for seemingly arbitrary rules, like how components must return a single top-level element. But more often than not, React is just warning us about a JavaScript limitation.

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

jesperlang• 4 years ago

I find it better to actually look at the AST for javascript.

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!

lucideer• 4 years ago

Probably worth adding "(javascript)" to the HN title - for non-JS see @nivertech's excellent comment here.

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

hardwaregeek• 4 years ago

This is why taking a basic programming language course is pretty important. I never remembered the difference until I had to represent both in an AST. You can teach it without talking about ASTs or interpreters, but it's teaching without any context or motivation, thereby making it harder to learn.

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.

tomxor• 4 years ago

I feel like the examples and description for "statements" fails to demonstrate their breadth.

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.

substation13• 4 years ago

They should deprecate Array.prototype.forEach for muddling statements and expressions!

gumby3• 4 years ago

One of the nice things about Lisp is there are no statements, only expressions. It's easier to think about your code.

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.

zabzonk2• 4 years ago

Understand where you are coming from, but given the nature of C, what is the compiler to do with something like:

    1 2 3

which are three expressions, and probably the programmer meant "123". Of course:

    1; 2; 3;

is OK.

gumby3• 4 years ago

But that’s the point: what value does a language gain by making the distinction? It removes composability for no gain.

goto112• 4 years ago

Haskell is also based on an everything-is-an-expression syntax, but ended up re-inventing statements one level up, in the do-notation blocks.

To me, this indicates there is some merit to the statement/expression distinction.

sixbrx• 4 years ago

I'd say Haskell didn't reinvent statements so much as it just modeled them. That allows manipulating them before they are interpreted, which is a good thing generally.

S1ngleM4lt2• 4 years ago

As someone who had recently started going the other direction, from C and C-based languages to those more influenced by lisp, it took a bit of getting used to but I’ve grown to appreciate the expressiveness and composability. The only thing I can think of that statements allow, but as I understand it pure expressions don’t, would be early returns. The closest replacement I’ve seen is to just make “return” raise an exception and wrap the whole expression with the try/catch equivalent, which isn’t terrible but was a bit surprising coming from a C-based background where returning early is a fairly common pattern.

Jtsummers2• 4 years ago

You shouldn't need to raise exceptions for early returns. You can usually restructure your program to provide for the proper return without needing to use a return or comparable form when using an expression oriented language. If you had this C snippet, for instance:

  int foo(...) {
    if (condition) return an_expression;
    ...
    return another_expression;
  }

You'd put everything after that if into the else part instead of dropping it (like you would in C):

  (defun foo (...)
    (if condition
      an-expression
      (progn
        ...
        another-expression))) ;; and this /progn/ form would possibly be extracted to a new function if it was too long

Or more likely a cond if using Common Lisp and there were more than two cases:

  (defun foo (...)
    (cond (condition an-expression)
          ...
          (t
             ...
             another-expression)))

And in Common Lisp (and some others) you can still get a return form, using return-from in particular, from functions if you want to keep something more like the C-ish form:

  (defun foo (...)
    (when condition (return-from foo an-expression))
    ...
    another-expression))

chrismorgan2• 4 years ago

(5 + 1) * 2

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")      ←
  }

beeforpork• 4 years ago

I am puzzled. 'statement' and 'expression' are items of JavaScript syntax (or C or Java or C++ or Perl or whatever). So to explain it, you point to the syntax definition.

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.

photochemsyn• 4 years ago

I've been reading this on functional JS:

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?

filoeleven• 4 years ago

That example is particularly confusing because it’s a function definition written as an assignment for IMO no good reason. The outcome is the same either way, but

  function filter(predicate, xs) { return xs.filter(predicate) }

lets you know immediately that “filter” is a function, not a value. There are valid cases where assigning an anonymous function a name via “const” is appropriate, for example when working with higher-order functions, but most of the time it’s not necessary or helpful. I wish it hadn’t caught on.

EDIT: I should have read your comment more carefully. The example function is not a HOF though, it runs xs.filter(pred) when called. A HOF would be

  function addConst(x) ( return (y) => x + y }
  const add3 = addConst(3)
  add3(5) // returns 8

The second line can still be written as

  function add3(x) { return addConst(3) }

I think people use the const form because there’s less text to write. Syntax highlighting makes this form more bearable, but I still don’t like it.

bern44443• 4 years ago

Something that clicked for me recently in JS and specifically React was why we use {} for interpolation in a component. So an example:

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

Curly braces often denote expressions. They're everywhere:

In functions:

  const x = () => {

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

In conditionals (while the conditionals are statements their bodies are expressions)

  if (x > 2) {
    return true;
  }

In Loops

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

etc.

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.

Statements vs. Expressions

Related Stories