“Semantics” is “meaning”. A language has syntax and semantics—syntax is about the form of valid programs in the language, semantics is about what those programs are supposed to mean.
We want to use formal semantics when writing documentation about a language, so that a programmer can predict how their program should work, and so different compilers can be sure they treat normal programs the same way.
Often we define the semantics for a language with *operational* semantics, where we write a set of *rules* for what a program should *do* (how it operates), for example:
“If `E1` is an expression that evaluates to a value `V1`, and `E2` is an expression that evaluates to a value `V2`, then the expression `(E1, E2)` evaluates to the pair of values `(V1, V2)`; but if `E1` evaluates to an error `X1`, then `(E1, E2)` evaluates to `X1`; and if `E1` evaluates to a value `V1` but `E2` evaluates to an error `X2`, then `(E1, E2)` evaluates to `X2`.”
We’d usually write that in a shorter way using a math notation called *sequents*, but we don’t need to get into the details of that. The point is just to spell out exactly what it means for the language to behave in the way we want—in this case, subexpressions are eagerly evaluated from left to right, and may have effects like raising an error.
These rules can also be written as an *abstract machine*, which is a model of a simplified computer that only includes the details that are relevant to the language. An abstract machine can often be translated directly into a *virtual machine*, which is one way of running programs on a real computer.
Latest Answers