为了解释表达式和语句在可组合性(可链接性)方面的重要区别，我最喜欢的参考文献是John Backus的图灵奖论文《编程可以从冯·诺伊曼风格中解放出来吗?》

命令式语言(Fortran, C, Java，…)强调用语句来构造程序，并有表达式作为一种事后思考。函数式语言强调表达式。纯函数式语言具有如此强大的表达式，以至于可以完全消除语句。

表达式

一段可以求值的语法。换句话说，表达式是表达式元素的累积，如字面量、名称、属性访问、操作符或函数调用，它们都返回一个值。与许多其他语言相比，并不是所有的语言结构都是表达式。还有一些语句不能用作表达式，比如while。赋值也是语句，而不是表达式。

声明

语句是套件(代码“块”)的一部分。语句可以是表达式，也可以是带有关键字的几个结构之一，如if、while或for。

很简单:表达式的值是一个值，而语句不是。

为了改进和验证我之前的回答，编程语言术语的定义应该从计算机科学类型理论中解释。

表达式具有除Bottom类型以外的其他类型，即它有一个值。语句具有Unit或Bottom类型。

由此可见，语句只有在产生副作用时才能在程序中发挥作用，因为它要么不能返回值，要么只返回Unit类型的值，而Unit类型的值要么不可赋值(在某些语言中，如C的void)，要么可以存储以用于语句的延迟求值。

显然，@pragma或/*comment*/没有类型，因此与语句有所区别。因此，唯一没有副作用的语句类型是非操作。非手术治疗只能作为未来副作用的占位符。由于声明而采取的任何其他行动都是副作用。同样，编译器提示，例如@pragma，不是语句，因为它没有类型。

关于基于表达式的语言的一些事情:

最重要的是:所有内容都返回一个值

用于分隔代码块和表达式的花括号和大括号之间没有区别，因为所有内容都是表达式。不过，这并不会阻止词法作用域:例如，可以为包含其定义的表达式和该表达式中包含的所有语句定义局部变量。

在基于表达式的语言中，所有内容都返回一个值。这一开始可能有点奇怪——(FOR i = 1 TO 10 DO (print i))返回什么?

一些简单的例子:

(1)返回1 (1 + 1)返回2 (1 == 1)返回TRUE (1 == 2)返回FALSE (IF 1 == 1 THEN 10 ELSE 5)返回10 (IF 1 == 2 THEN 10 ELSE 5)返回5

还有一些更复杂的例子:

Some things, such as some function calls, don't really have a meaningful value to return (Things that only produce side effects?). Calling OpenADoor(), FlushTheToilet() or TwiddleYourThumbs() will return some sort of mundane value, such as OK, Done, or Success. When multiple unlinked expressions are evaluated within one larger expression, the value of the last thing evaluated in the large expression becomes the value of the large expression. To take the example of (FOR i = 1 TO 10 DO (print i)), the value of the for loop is "10", it causes the (print i) expression to be evaluated 10 times, each time returning i as a string. The final time through returns 10, our final answer

通常需要稍微改变一下心态，才能最大限度地利用基于表达式的语言，因为所有东西都是表达式，这使得“内联”很多东西成为可能

举个简单的例子:

FOR i = 1 to (IF MyString == "Hello, World!"然后就有10个人这样做了 （ LotsOfCode )

非基于表达式的替换是否完全有效

IF MyString == "Hello, World!"THEN TempVar = 10 ELSE TempVar = 5 FOR i = 1 TO TempVar DO （ LotsOfCode ）

在某些情况下，基于表达式的代码所允许的布局对我来说感觉更自然

当然，这可能导致疯狂。作为基于表达式的脚本语言MaxScript的爱好项目的一部分，我设法想出了这个怪物行

IF FindSectionStart "rigidifiers" != 0 THEN FOR i = 1 TO (local rigidifier_array = (FOR i = (local NodeStart = FindsectionStart "rigidifiers" + 1) TO (FindSectionEnd(NodeStart) - 1) collect full_array[i])).count DO
(
    LotsOfCode
)

这些概念的事实基础是:

表达式:一种语法类别，其实例可以求值。

语句:一种语法类别，其实例可能涉及表达式的求值，并且不能保证求值的结果值(如果有的话)可用。

除了最初几十年的FORTRAN上下文之外，公认答案中表达式和语句的定义显然都是错误的:

Expressions can be unvaluated operands. Values are never produced from them. Subexpressions in non-strict evaluations can be definitely unevaluated. Most C-like languages have the so-called short-circuit evaluation rules to conditionally skip some subexpression evaluations not change the final result in spite of the side effects. C and some C-like languages have the notion of unevaluated operand which may be even normatively defined in the language specification. Such constructs are used to avoid the evaluations definitely, so the remained context information (e.g. types or alignment requirements) can be statically distinguished without changing the behavior after the program translation. For example, an expression used as the operand of the sizeof operator is never evaluated. Statements have nothing to do with line constructs. They can do something more than expressions, depending on the language specifications. Modern Fortran, as the direct descendant of the old FORTRAN, has concepts of executable statements and nonexecutable statements. Similarly, C++ defines declarations as the top-level subcategory of a translation unit. A declaration in C++ is a statement. (This is not true in C.) There are also expression-statements like Fortran's executable statements. To the interest of the comparison with expressions, only the "executable" statements matter. But you can't ignore the fact that statements are already generalized to be constructs forming the translation units in such imperative languages. So, as you can see, the definitions of the category vary a lot. The (probably) only remained common property preserved among these languages is that statements are expected to be interpreted in the lexical order (for most users, left-to-right and top-to-bottom).

(BTW，关于C的材料，我想补充一下[引文]，因为我不记得DMR是否有这样的意见。似乎不是，否则就没有理由在C语言的设计中保留功能重复:特别是逗号操作符和语句。)

(以下基本原理并不是对最初问题的直接回应，但我觉得有必要澄清这里已经回答过的一些问题。)

然而，在通用编程语言中，我们是否需要特定类别的“语句”是值得怀疑的:

Statements are not guaranteed to have more semantic capabilities over expressions in usual designs. Many languages have already successfully abandon the notion of statements to get clean, neat and consistent overall designs. In such languages, expressions can do everything old-style statements can do: just drop the unused results when the expressions are evaluated, either by leaving the results explicitly unspecified (e.g. in RnRS Scheme), or having a special value (as a value of a unit type) not producible from normal expression evaluations. The lexical order rules of evaluation of expressions can be replaced by explicit sequence control operator (e.g. begin in Scheme) or syntactic sugar of monadic structures. The lexical order rules of other kinds of "statements" can be derived as syntactic extensions (using hygienic macros, for example) to get the similar syntactic functionality. (And it can actually do more.) On the contrary, statements cannot have such conventional rules, because they don't compose on evaluation: there is just no such common notion of "substatement evaluation". (Even if any, I doubt there can be something much more than copy and paste from existed rules of evaluation of expressions.) Typically, languages preserving statements will also have expressions to express computations, and there is a top-level subcategory of the statements preserved to expression evaluations for that subcategory. For example, C++ has the so-called expression-statement as the subcategory, and uses the discarded-value expression evaluation rules to specify the general cases of full-expression evaluations in such context. Some languages like C# chooses to refine the contexts to simplify the use cases, but it bloats the specification more. For users of programming languages, the significance of statements may confuse them further. The separation of rules of expressions and statements in the languages requires more effort to learn a language. The naive lexical order interpretation hides the more important notion: expression evaluation. (This is probably most problematic over all.) Even the evaluations of full expressions in statements are constraint with the lexical order, subexpressions are not (necessarily). Users should ultimately learn this besides any rules coupled to the statements. (Consider how to make a newbie get the point that ++i + ++i is meaningless in C.) Some languages like Java and C# further constraints the order of evaluations of subexpressions to be permissive of ignorance of evaluation rules. It can be even more problematic. This seems overspecified to users who have already learned the idea of expression evaluation. It also encourages the user community to follow the blurred mental model of the language design. It bloats the language specification even more. It is harmful to optimization by missing the expressiveness of nondeterminism on evaluations, before more complicated primitives are introduced. A few languages like C++ (particularly, C++17) specify more subtle contexts of evaluation rules, as a compromise of the problems above. It bloats the language specification a lot. This goes totally against to simplicity to average users...

为什么是语句?不管怎样，历史已经一团糟了。似乎大多数语言设计者都没有仔细选择。

更糟糕的是，它甚至让一些类型系统爱好者(他们对PL历史不够熟悉)产生了一些误解，认为类型系统必须与操作语义上更基本的规则设计有重要关系。

严肃地说，基于类型的推理在许多情况下并不是那么糟糕，但在这个特殊情况下尤其没有建设性。即使是专家也会把事情搞砸。

For example, someone emphasizes the well-typing nature as the central argument against the traditional treatment of undelimited continuations. Although the conclusion is somewhat reasonable and the insights about composed functions are OK (but still far too naive to the essense), this argument is not sound because it totally ignores the "side channel" approach in practice like _Noreturn any_of_returnable_types (in C11) to encode Falsum. And strictly speaking, an abstract machine with unpredictable state is not identical to "a crashed computer".