Expression-oriented programming language

An expression-oriented programming language is a programming language where (nearly) every construction is an expression and thus yields a value. The typical exceptions are macro definitions, preprocessor commands, and declarations, which expression-oriented languages often treat as statements rather than expressions. Some expression-oriented languages introduce a void return type to be yielded by expressions that merely cause side-effects.

ALGOL 68 is an example of an expression-oriented language. Pascal is not. All functional programming languages are expression-oriented.

Criticism

Critics^[1][2], including language designers^[3], blame expression-orientation for an entire class of programming mistake wherein the programmer introduces an assignment expression where he meant to test for equality. For example, the designers of Ada and Java were so worried about this type of mistake, they restricted control expressions to those that evaluate strictly to the boolean data type.^[4][5] Python takes the alternative strategy of implementing assignment as a statement rather than an expression, thus prohibiting assignment from nesting inside of any other statement or expression.^[6] Here is an example of one phrasal of the allegation:

Expression-orientation can be confusing in imperative programming languages, as many commands used normally as statements are in fact expressions. For example, assignment in the C programming language is an expression, not a statement. This allows for the following confusion:

if (x = 1) {
 ...
} else {
  /* this branch is never executed */
}

The condition of the if is the result of the expression x = 1, which is 1. Thus the if will always execute the true branch. The above is often confused with:

if (x == 1) {
  ... /* executed if x is 1 */
} else {
  ... /* executed if x is not 1 */
}

However, we understand the root of such mistakes better if we blame notation rather than semantics. From the perspective of expression-orientation, the choice of assignment notation made by C-style languages, the notorious equals sign, “=”, is a poor choice for multiple reasons, not the least of which is that it encourages programmers to misuse the misleading verb “equals” when they recite a program’s logic in oral English, instead of the more informative verb “gets”. Most relevant to the present discussion, the equals sign’s similarity to, and hazardously small (inadequate) typing distance^{[nb 1]} from the notation C-style languages choose for the equality operator, “==”, make it an occasion for error. The expression-ness of assignment is not the culprit here. Other language families make better notational choices for assignment^[7], such as variable ← expression in APL or variable <- expression in Objective Caml, S, and R. It is also possible to dispense with the assignment operator entirely, as in Lisp and Scheme’s (setq variable expression).

Notes

1. In fact, considering the automatic repetition feature of typical computer keyboards, the minimum string distance between = and == is effectively zero, the worst possible collision.

References

1. Assignment versus equality
2. Confusion with assignment operators
3. Java Code Conventions "10.4 Variable Assignments"
4. Java Language Specification "14.9 The if Statement"
5. Introducing Ada
6. The Python Language Reference "6.2. Assignment statements"
7. Rigaux, Pascal (2008-08-29 08:32:23). "Syntax Across Languages: Assignment or Declaration" (html). Language Study. SourceForge. Retrieved 2010-04-17. {{cite web}}: Check |authorlink= value (help); Check date values in: |date= (help); External link in |authorlink= (help)