<p>I have thought about how I could specify an expression separate from a statement.</p>
<blockquote>
<p>A fragment of code that resolves to a value.</p>
</blockquote>
<p>But <code>void</code> expressions are still expressions but do not really resolve to a value.</p>
<blockquote>
<p>A fragment of code that performs an action.</p>
</blockquote>
<p>Includes statements too.</p>
<blockquote>
<p>An assignment or function call or literal value or variable.</p>
</blockquote>
<p>An ostensibly exhaustive list is a cop-out.</p>
<p>How could I best define an <em>expression</em> separately from a <em>statement</em>?</p>
<p><em><strong>Note:</strong> The top-voted answer <a href="https://languagedesign.meta.stackexchange.com/q/157/38">here</a> permits such questions.</em></p>

<expressions><terminology><statements><specification>
How would I describe an expression separately from a statement?
CC BY-SA 4.0
2023-05-22T22:34:46.520Z
*"An ostensibly exhaustive list is a cop-out."* ─ Why? This is what many real language specifications do.
kaya3
CC BY-SA 4.0
2023-05-22T23:05:04.107Z
@kaya3 It just says a bunch of things which are expressions. It does not really say why they are expressions or what an expression **really is** or **means**.
CPlus
CC BY-SA 4.0
2023-05-23T21:19:37.397Z
What difference do you intend to make between “expression” and “statement”? This is very dependent on the language. Some languages make no difference at all (e.g. Lisp). In some languages, statements are expressions that return `void`. In some languages, expressions are one kind of statement, and there are others, but even in such languages, the impact of a statement being an expression differs: for example, in standard C, an expression cannot contain loops except buried under function calls, but in GCC-extended C, an expression can contain a statement. What's your language like?
Gilles 'SO- stop being evil'
<h1>Just list them</h1>
<p>The <a href="https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/statements" rel="nofollow noreferrer">C# language specification</a> and current draft <a href="https://tc39.es/ecma262/multipage/ecmascript-language-statements-and-declarations.html#sec-ecmascript-language-statements-and-declarations" rel="nofollow noreferrer">ECMAScript specification</a> both opt to not define what a statement is, and instead just give a list of what statements exist.</p>
<p><a href="https://docs.swift.org/swift-book/documentation/the-swift-programming-language/statements" rel="nofollow noreferrer"><em>The Swift Programming Language</em></a> defines it in paragraph form, but again by listing different types of statements rather than giving a singular definition:</p>
<blockquote>
<p>In Swift, there are three kinds of statements: simple statements, compiler control statements, and control flow statements. Simple statements are the most common and consist of either an expression or a declaration. Compiler control statements allow the program to change aspects of the compiler’s behavior and include a conditional compilation block and a line control statement.</p>
<p>Control flow statements are used to control the flow of execution in a program. There are several types of control flow statements in Swift, including loop statements, branch statements, and control transfer statements. Loop statements allow a block of code to be executed repeatedly, branch statements allow a certain block of code to be executed only when certain conditions are met, and control transfer statements provide a way to alter the order in which code is executed. In addition, Swift provides a <code>do</code> statement to introduce scope, and catch and handle errors, and a <code>defer</code> statement for running cleanup actions just before the current scope exits.</p>
</blockquote>

CC BY-SA 4.0
2023-05-22T22:15:20.113Z
2023-05-22T22:15:20.113Z
Bbrk24
<p>The meaning of the words &quot;expression&quot; and &quot;statement&quot; depend on context.</p>
<p>In a language's grammar, these words just refer to syntactic forms. It is not strictly correct to say that a syntactically valid expression like <code>1 + x</code> produces a value when executed, because this expression cannot even necessarily <em>be</em> executed. For example, <code>x</code> could be the wrong type, or there might be no such variable named <code>x</code>, and then this expression could not be compiled and would never be able to produce a value. Or it could be something semantically valid like <code>System.out.println(&quot;Hello, world!&quot;)</code> in Java, which doesn't produce a value (because it invokes a <code>void</code> method), but is nonetheless an expression according to Java's grammar. So the best we can say is that expressions are grammatical forms which <em>typically</em> correspond with computations that produce values, and statements are grammatical forms which <em>typically</em> correspond with instructions which change the program state.</p>
<p>Or in abstract syntax trees, expressions and statements are kinds of nodes. Expression nodes <em>typically</em> would produce values when evaluated, and statement nodes <em>typically</em> would change the program state when executed. But even in the AST, we generally don't insist that an expression must e.g. pass type-checking in order for it to <em>be</em> an expression, so expressions need not actually be evaluable; likewise for statements.</p>
<p>On the other hand, in an intermediate representation used after name resolution, type-checking and other checks have occurred, we might only construct IR nodes which are semantically valid. In this case, a statement or expression in the IR would always represent something evaluable. However, depending on implementation, the IR might not distinguish statements from expressions at all; for example, a statement <code>if(a) x = b; else x = c;</code> and an expression <code>a ? (x = b) : (x = c)</code> might be the same in some IR.</p>
<p>Note that these are descriptions, not definitions, so it's OK to use words like <em>&quot;typically&quot;</em> as long as it gets the idea across.</p>

CC BY-SA 4.0
2023-05-22T23:19:52.767Z
2024-06-15T02:20:46.133Z
2024-06-15T02:20:46.133Z
kaya3
<p>Describe them by how they can and cannot be used. For instance, in many languages, an expression can appear on the right side of an assignment statement, but a statement cannot. Thus, the following may be legal (because <code>x == 1 ? 3 : 2</code> is a conditional <em>expression</em>):</p>
<pre><code>x = x == 1 ? 3 : 2;
</code></pre>
<p>Whereas the following would be illegal in a language like C++ (because <code>if</code> indicates the start of a conditional <em>statement</em>):</p>
<pre><code>x = if (x == 1) { 3 } else { 2 };
</code></pre>

CC BY-SA 4.0
2023-05-22T22:22:59.913Z
2023-05-22T22:22:59.913Z
Isaiah
<p>&quot;Expression&quot; usually refers to a fragment of code that can be found as the condition of a conditional language construct, to what produces a value that can be saved into a variable per assignment or passed into a parameter (in-place evaluation of the expression), it's basically a syntax unit which produces a value result by performing the actual computation, calculation, logic operations or comparison (typically using operators on operands).</p>
<p><code>void</code> (or <code>nil</code> or similar) may act as a (pseudo-)value as well, just an empty one (depends on whether or not a language defines it as a proper/permitted result/value of expressions if it's handled in a compatible way similar to other expression results, otherwise with an incompatible design choice treating <code>void</code> special. Depends on if there's a constraint on <code>void</code> in the area of type checking, but if <code>void</code> could be the result of an expression, that might qualify as just another value. With &quot;expression&quot; being a certain category of language constructs, it's up to the language designer to decide whether <code>void</code> might be included in this category or not.</p>
<p>A &quot;statement&quot; on the other hand is considered to be broader. Expressions could be seen as statements too, if just found as standalone. But then there's statements that are not expressions. Declarations, various keywords, control flow constructs. These are not allowed to appear on the value-side of an assignment, or go as argument into a function parameter, etc., as these are not evaluated/resolved/computed-to some result, and instead perform actions.</p>
<p>Operators, performing an action, are not expressions themselves. Operators + operands make an expression. Value literals, function calls or variable names (as these resolve to a value) can be found in places which would also allow for an in-place larger expression which has to compute a value/result first.</p>

CC BY-SA 4.0
2024-06-14T23:43:27.783Z
2024-06-14T23:43:27.783Z
skreutzer
<p>A &quot;statement&quot; is generally anything that commands the computer to do something, and which is regarded as a single indivisible step in that programming language.</p>
<p>In block-structured languages, a block may be declared by keywords (or other syntactic elements) in a certain header/trailer arrangement, and the activity of the block controlled by the inclusion of statements in a certain arrangement (typically in the header).</p>
<p>I've seen these block keywords themselves called &quot;statements&quot; even though they cannot typically stand on their own, and the contents of the block called &quot;compound statements&quot; when those contents are a divisible series of statements capable of being free-standing.</p>
<p>I'd therefore suggest there isn't a universal consistency of what form a &quot;statement&quot; takes, except that its role broadly corresponds to a &quot;sentence&quot; in natural language - something often easier to identify by example than by definition.</p>
<p>An &quot;expression&quot; meanwhile is a series of  operators and operands and is capable of evaluation, and is a concept originally drawn from mathematics. In a computer context, evaluation doesn't mean literally producing a value, but rather it means piping arguments and results between operators in a systematic way (and implying the compatibility of the results of each round with the arguments of the next), and typically the reduction of two or more inputs into one or zero outputs.</p>
<p>In my view, an expression would be considered a specific type of statement or statement-part, rather than something distinguished from a statement, so that a statement may or may not be an expression, and may or may not contain one or more expressions.</p>

CC BY-SA 4.0
2024-07-28T21:13:28.930Z
2024-07-28T21:13:28.930Z
Steve
<p>&quot;Statements&quot; and &quot;expressions&quot; are kinds of nodes in some languages' grammars, <strong>including English</strong>.<br />
Those concepts may exist in the formally specified grammar, as in C-like languages, or not, as in languages in the ML, Haskell and Lisp families.</p>
<p>A statement is a node that can exist in a list, and an expression is one that can exist in a tree.<br />
Literally speaking, if you see an EBNF syntax looking like</p>
<pre><code>Function ::= &quot;fn&quot; Identifier Parameters? &quot;{&quot; Stuff* &quot;}&quot;
</code></pre>
<p>then <code>Stuff</code> is statements, as they can be listed.<br />
Meanwhile,</p>
<pre><code>Term ::= Addition | Number
Addition ::= Term &quot;+&quot; Term
</code></pre>
<p>then <code>Term</code> is an expression, as it is a tree.</p>
<p>This all is true even in languages that have nothing called &quot;statement&quot; in their formal grammar.<br />
Take Haskell: it has a kind of expression called <code>do</code>-notation representing abstract trees of nested Monadic operations flattened to lists.</p>
<p>This tree code:</p>
<pre class="lang-haskell prettyprint-override"><code>main =
    getLine &gt;&gt;= \str -&gt;
        putStrLn str
</code></pre>
<p>can be flattened to this list:</p>
<pre class="lang-haskell prettyprint-override"><code>main = do
    str &lt;- getLine
    putStrLn str
</code></pre>
<p>where <code>do</code>-notation's grammar is <code>&quot;do&quot; ((Identifier &quot;&lt;-&quot; | &quot;let&quot; Identifier &quot;=&quot;)? Expression)+</code>.<br />
And in this context, even though the grammar has no concept of &quot;statement,&quot; this is exactly the <a href="https://downloads.haskell.org/ghc/latest/docs/users_guide/ghci.html#using-do-notation-at-the-prompt" rel="nofollow noreferrer">documented and used term</a>.</p>
<p>Lisp is another expression-oriented family of languages where most of the syntax revolve around <code>Expr ::= &quot;(&quot; Identifier Expr* &quot;)&quot;</code>, and one of its functions, called <code>do</code>, just evaluates an arbitrary list of expressions as arguments.</p>
<pre class="lang-lisp prettyprint-override"><code>(do
    (println (+ 40 2))
    (println (* 21 2)))
</code></pre>
<p>Statements!<br />
This doesn't even need to be a builtin construct. You can define <code>do</code> as simply as a variadic function that ignores all its arguments.</p>
<p>TL;DR: Those are purely syntactic constructs with no bearings on semantics.</p>

CC BY-SA 4.0
2023-05-23T22:13:41.030Z
2023-05-24T01:14:23.990Z
2023-05-24T01:14:23.990Z
Longinus
# How would I describe an expression separately from a statement?
Posted by: username_0 on 2023-05-22
I have thought about how I could specify an expression separate from a statement.

> A fragment of code that resolves to a value.

But `void` expressions are still expressions but do not really resolve to a value.

> A fragment of code that performs an action.

Includes statements too.

> An assignment or function call or literal value or variable.

An ostensibly exhaustive list is a cop-out.

How could I best define an *expression* separately from a *statement*?

***Note:** The top-voted answer [here](https://languagedesign.meta.stackexchange.com/q/157/38) permits such questions.*
**Tags:** expressions terminology statements specification
> **Comments:**
> **username_1**: *"An ostensibly exhaustive list is a cop-out."* ─ Why? This is what many real language specifications do.  
> **username_0**: @kaya3 It just says a bunch of things which are expressions. It does not really say why they are expressions or what an expression **really is** or **means**.  
> **username_2**: What difference do you intend to make between “expression” and “statement”? This is very dependent on the language. Some languages make no difference at all (e.g. Lisp). In some languages, statements are expressions that return `void`. In some languages, expressions are one kind of statement, and there are others, but even in such languages, the impact of a statement being an expression differs: for example, in standard C, an expression cannot contain loops except buried under function calls, but in GCC-extended C, an expression can contain a statement. What's your language like?  
---
## 6 answers
### Answer by username_7 on 2023-05-23. Score: 3 | Accepted answer
"Statements" and "expressions" are kinds of nodes in some languages' grammars, including English.
Those concepts may exist in the formally specified grammar, as in C-like languages, or not, as in languages in the ML, Haskell and Lisp families.
A statement is a node that can exist in a list, and an expression is one that can exist in a tree.
Literally speaking, if you see an EBNF syntax looking like
Function ::= "fn" Identifier Parameters? "{" Stuff* "}"

then Stuff is statements, as they can be listed.
Meanwhile,
Term ::= Addition | Number
Addition ::= Term "+" Term

then Term is an expression, as it is a tree.
This all is true even in languages that have nothing called "statement" in their formal grammar.
Take Haskell: it has a kind of expression called do-notation representing abstract trees of nested Monadic operations flattened to lists.
This tree code:
main =
    getLine >>= \str ->
        putStrLn str

can be flattened to this list:
main = do
    str <- getLine
    putStrLn str

where do-notation's grammar is "do" ((Identifier "<-" | "let" Identifier "=")? Expression)+.
And in this context, even though the grammar has no concept of "statement," this is exactly the documented and used term.
Lisp is another expression-oriented family of languages where most of the syntax revolve around Expr ::= "(" Identifier Expr* ")", and one of its functions, called do, just evaluates an arbitrary list of expressions as arguments.
(do
    (println (+ 40 2))
    (println (* 21 2)))

Statements!
This doesn't even need to be a builtin construct. You can define do as simply as a variadic function that ignores all its arguments.
TL;DR: Those are purely syntactic constructs with no bearings on semantics.
---
### Answer by username_3 on 2023-05-22. Score: 4
# Just list them

The [C# language specification](https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/statements) and current draft [ECMAScript specification](https://tc39.es/ecma262/multipage/ecmascript-language-statements-and-declarations.html#sec-ecmascript-language-statements-and-declarations) both opt to not define what a statement is, and instead just give a list of what statements exist.

[*The Swift Programming Language*](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/statements) defines it in paragraph form, but again by listing different types of statements rather than giving a singular definition:

> In Swift, there are three kinds of statements: simple statements, compiler control statements, and control flow statements. Simple statements are the most common and consist of either an expression or a declaration. Compiler control statements allow the program to change aspects of the compiler’s behavior and include a conditional compilation block and a line control statement.
>
> Control flow statements are used to control the flow of execution in a program. There are several types of control flow statements in Swift, including loop statements, branch statements, and control transfer statements. Loop statements allow a block of code to be executed repeatedly, branch statements allow a certain block of code to be executed only when certain conditions are met, and control transfer statements provide a way to alter the order in which code is executed. In addition, Swift provides a `do` statement to introduce scope, and catch and handle errors, and a `defer` statement for running cleanup actions just before the current scope exits.
---
### Answer by username_1 on 2023-05-22. Score: 4
The meaning of the words "expression" and "statement" depend on context.

In a language's grammar, these words just refer to syntactic forms. It is not strictly correct to say that a syntactically valid expression like `1 + x` produces a value when executed, because this expression cannot even necessarily *be* executed. For example, `x` could be the wrong type, or there might be no such variable named `x`, and then this expression could not be compiled and would never be able to produce a value. Or it could be something semantically valid like `System.out.println("Hello, world!")` in Java, which doesn't produce a value (because it invokes a `void` method), but is nonetheless an expression according to Java's grammar. So the best we can say is that expressions are grammatical forms which *typically* correspond with computations that produce values, and statements are grammatical forms which *typically* correspond with instructions which change the program state.

Or in abstract syntax trees, expressions and statements are kinds of nodes. Expression nodes *typically* would produce values when evaluated, and statement nodes *typically* would change the program state when executed. But even in the AST, we generally don't insist that an expression must e.g. pass type-checking in order for it to *be* an expression, so expressions need not actually be evaluable; likewise for statements.

On the other hand, in an intermediate representation used after name resolution, type-checking and other checks have occurred, we might only construct IR nodes which are semantically valid. In this case, a statement or expression in the IR would always represent something evaluable. However, depending on implementation, the IR might not distinguish statements from expressions at all; for example, a statement `if(a) x = b; else x = c;` and an expression `a ? (x = b) : (x = c)` might be the same in some IR.

Note that these are descriptions, not definitions, so it's OK to use words like *"typically"* as long as it gets the idea across.
---
### Answer by username_4 on 2023-05-22. Score: 4
Describe them by how they can and cannot be used. For instance, in many languages, an expression can appear on the right side of an assignment statement, but a statement cannot. Thus, the following may be legal (because x == 1 ? 3 : 2 is a conditional expression):
x = x == 1 ? 3 : 2;

Whereas the following would be illegal in a language like C++ (because if indicates the start of a conditional statement):
x = if (x == 1) { 3 } else { 2 };
---
### Answer by username_5 on 2024-06-14. Score: 1
"Expression" usually refers to a fragment of code that can be found as the condition of a conditional language construct, to what produces a value that can be saved into a variable per assignment or passed into a parameter (in-place evaluation of the expression), it's basically a syntax unit which produces a value result by performing the actual computation, calculation, logic operations or comparison (typically using operators on operands).

`void` (or `nil` or similar) may act as a (pseudo-)value as well, just an empty one (depends on whether or not a language defines it as a proper/permitted result/value of expressions if it's handled in a compatible way similar to other expression results, otherwise with an incompatible design choice treating `void` special. Depends on if there's a constraint on `void` in the area of type checking, but if `void` could be the result of an expression, that might qualify as just another value. With "expression" being a certain category of language constructs, it's up to the language designer to decide whether `void` might be included in this category or not.

A "statement" on the other hand is considered to be broader. Expressions could be seen as statements too, if just found as standalone. But then there's statements that are not expressions. Declarations, various keywords, control flow constructs. These are not allowed to appear on the value-side of an assignment, or go as argument into a function parameter, etc., as these are not evaluated/resolved/computed-to some result, and instead perform actions.

Operators, performing an action, are not expressions themselves. Operators + operands make an expression. Value literals, function calls or variable names (as these resolve to a value) can be found in places which would also allow for an in-place larger expression which has to compute a value/result first.
---
### Answer by username_6 on 2024-07-28. Score: 0
A "statement" is generally anything that commands the computer to do something, and which is regarded as a single indivisible step in that programming language.

In block-structured languages, a block may be declared by keywords (or other syntactic elements) in a certain header/trailer arrangement, and the activity of the block controlled by the inclusion of statements in a certain arrangement (typically in the header).

I've seen these block keywords themselves called "statements" even though they cannot typically stand on their own, and the contents of the block called "compound statements" when those contents are a divisible series of statements capable of being free-standing.

I'd therefore suggest there isn't a universal consistency of what form a "statement" takes, except that its role broadly corresponds to a "sentence" in natural language - something often easier to identify by example than by definition.

An "expression" meanwhile is a series of operators and operands and is capable of evaluation, and is a concept originally drawn from mathematics. In a computer context, evaluation doesn't mean literally producing a value, but rather it means piping arguments and results between operators in a systematic way (and implying the compatibility of the results of each round with the arguments of the next), and typically the reduction of two or more inputs into one or zero outputs.

In my view, an expression would be considered a specific type of statement or statement-part, rather than something distinguished from a statement, so that a statement may or may not be an expression, and may or may not contain one or more expressions.
---
