Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p><strong>Expression:</strong> Something which evaluates to a value. Example: <em>1+2/x</em><br> <strong>Statement:</strong> A line of code which does something. Example: <em>GOTO 100</em></p> <p>In the earliest general-purpose programming languages, like FORTRAN, the distinction was crystal-clear. In FORTRAN, a statement was one unit of execution, a thing that you did. The only reason it wasn't called a "line" was because sometimes it spanned multiple lines. An expression on its own couldn't do anything... you had to assign it to a variable.</p> <blockquote> <p><code>1 + 2 / X</code></p> </blockquote> <p>is an error in FORTRAN, because it doesn't do anything. You had to do something with that expression:</p> <blockquote> <p><code>X = 1 + 2 / X</code></p> </blockquote> <p>FORTRAN didn't have a grammar as we know it today&mdash;that idea was invented, along with Backus-Naur Form (BNF), as part of the definition of Algol-60. At that point the <em>semantic</em> distinction ("have a value" versus "do something") was enshrined in <em>syntax</em>: one kind of phrase was an expression, and another was a statement, and the parser could tell them apart.</p> <p>Designers of later languages blurred the distinction: they allowed syntactic expressions to do things, and they allowed syntactic statements that had values. The earliest popular language example that still survives is C. The designers of C realized that no harm was done if you were allowed to evaluate an expression and throw away the result. In C, every syntactic expression can be a made into a statement just by tacking a semicolon along the end:</p> <blockquote> <p><code>1 + 2 / x;</code></p> </blockquote> <p>is a totally legit statement even though absolutely nothing will happen. Similarly, in C, an expression can have <em>side-effects</em>&mdash;it can change something.</p> <blockquote> <p><code>1 + 2 / callfunc(12);</code></p> </blockquote> <p>because <code>callfunc</code> might just do something useful.</p> <p>Once you allow any expression to be a statement, you might as well allow the assignment operator (=) inside expressions. That's why C lets you do things like</p> <blockquote> <p><code>callfunc(x = 2);</code></p> </blockquote> <p>This evaluates the expression x = 2 (assigning the value of 2 to x) and then passes that (the 2) to the function <code>callfunc</code>.</p> <p>This blurring of expressions and statements occurs in all the C-derivatives (C, C++, C#, and Java), which still have some statements (like <code>while</code>) but which allow almost any expression to be used as a statement (in C# only assignment, call, increment, and decrement expressions may be used as statements; see <a href="https://stackoverflow.com/a/20771/8554766">Scott Wisniewski's answer</a>).</p> <p>Having two "syntactic categories" (which is the technical name for the sort of thing statements and expressions are) can lead to duplication of effort. For example, C has two forms of conditional, the statement form</p> <pre><code>if (E) S1; else S2; </code></pre> <p>and the expression form</p> <pre><code>E ? E1 : E2 </code></pre> <p>And sometimes people <em>want</em> duplication that isn't there: in standard C, for example, only a statement can declare a new local variable&mdash;but this ability is useful enough that the GNU C compiler provides a GNU extension that enables an expression to declare a local variable as well.</p> <p>Designers of other languages didn't like this kind of duplication, and they saw early on that if expressions can have side effects as well as values, then the <em>syntactic</em> distinction between statements and expressions is not all that useful&mdash;so they got rid of it. Haskell, Icon, Lisp, and ML are all languages that don't have syntactic statements&mdash;they only have expressions. Even the class structured looping and conditional forms are considered expressions, and they have values&mdash;but not very interesting ones.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload