Javascript: difference between a statement and an expression?

Question

I asked this question earlier, and after thinking about the topic some more, I began to wonder where the seemingly fuzzy boundary between the meanings of the terms "statement" and "expression" lies. Are all statements also expressions? Where do the return values in a REPL console come from? They don't always seem to make any intuitive sense. Of course if you type 1+1, you'll get 2, but other times it isn't as obvious what the logic is.

Given that anything typed into REPL produces some value, does it mean that it can be used in JS source code as both an expression and a standalone statement?

can string of code that could be used for _X_ in the following snippet also be used for _Y_ and vice versa? if(_X_) _Y_

Answer 1

Are all statements also expressions?

“Wherever JavaScript expects a statement, you can also write an expression. Such a statement is called an expression statement. The reverse does not hold: you cannot write a statement where JavaScript expects an expression. For example, an if statement cannot become the argument of a function.”

This is comes from a recent post by Axel Rauschmayer about this topic: Expressions versus statements in JavaScript

Hope it helps.

Answer 2

According to MDN:

An expression is any valid unit of code that resolves to a value.

As such, anything that can be used as an rvalue is an expression.

The criterion is not whether side effects exist. Expressions can definitely have side effects. E.g. a=2 is an expression as it has a value (2) and also assigns a value to a variable. Which is why you can do things like:

let a; let b = 1 + (a = 2); // a is now 2 and b is 3 

It is possible for the same (textual) block of code to be considered both an expression and a statement depending on the context. E.g. the text snippet function f(){} is an expression on line 1 and a statement in line 2 in the below code:

let g = function f() {}; function f() {}; 

So whether something is an expression or a statement cannot (in the general case) be determined by looking at a textual piece of code out of context; rather it is a property of a node in a syntax tree and can be decided only after the code is (mentally or actually) parsed.

Also, and perhaps more importantly, function statements (a.k.a function declarations) inside a function f form part of the execution context that gets created when function f is invoked. However, function expressions do not form part of that execution context.

One often quoted effect of that is that function declarations get "hoisted" whereas function expressions do not.

A more subtle effect can also be experimentally observed in deep recursions given that function statements take up space in the execution context whereas function expressions do not. E.g. the below code uses infinite recursion of a function f. Function f in the first case includes a function expression inside it, in the second case it includes the equivalent function declaration:

// Function Expression {     let i = 0;     try {          function f () {             i++;             (function g() {})(); // this is an expression             f();         }          f();      } catch (err) {         console.log(`Function Expressions case: depth of ${i} reached. Error: ${err.name}`);     } } // Function Declaration {     let i = 0;     try {         function f () {             i++;             function g() {}; // this is a statement             g();             f();         }          f();      } catch (err) {         console.log(`Functions Declarations case: depth of ${i} reached. Error: ${err.name}`);     } } 

On my machine I consistently get the following (in node.js):

Function Expressions case: depth of 17687 reached. Error: RangeError Functions Declarations case: depth of 15476 reached. Error: RangeError 

… which is consistent with the fact that Function Declarations increase the amount of space necessary to hold an execution context and thus eat up stack space a little faster and so slightly decrease the maximum recursion depth.