The following is concerned with clarifying what is meant by imperative programming language variables - i.e. variables which are accessed by imperative statements in imperative programming languages, and not to be confused with variables used in other contexts - such as variables appearing in:
Chris Date in his book An Introduction to Database Systems characterises a variable as follows:
A variable is a holder for an appearance of a value. A variable does have a location in time and space. Also, of course, variables, unlike values, can be updated; this is, the current value of the variable in question can be replaced by another value, probably different from the previous one. (Of course, the variable in question is still the same variable after the update.)
Obviously, this is only informal and only intended to be used to introduce the basic notions of values, variables and types. Nevertheless this characterises a variable as what could more accurately be described as a mutable L-value in a physical computer.
In the following, source code refers to a program text written in an imperative programming language.
Chris Date's characterisation assumes a variable is updatable. That ignores the important and very common notion of read-only variables. For example:
A physical computational machine refers to a physical computer that exists in space and time.
An abstract computational machine refers to a computational machine defined in a pure mathematical formalism, which doesn't exist physically in space and time.
Chris Date's characterisation speaks of variables existing in space and time which apparently assumes that variables (only) exist on physical computers
For the purposes of defining a platform independent imperative programming language, it is appropriate to define semantics in a pure mathematical formalismn - i.e. for an abstract machine. Therefore any notion of programming variables is defined in relation to an abstract machine. Any notions of some correspondence to a physical machine is an implementational detail, and outside the scope of the language specification.
The following distinctions are made:
A L-value is a holder for the appearance of a value within a computational machine - what perhaps might be called a storage location. Whether the computational machine is abstract is unspecified, but as noted above a language specification generally defines semantics on an abstract machine, and in that case a L-value would be abstract we well.
It is possible to distinguish between read-only L-values and mutable L-values.
A variable is an individual identifier appearing in source code which is used to refer to an L-value.
An L-value expression is an expression appearing in source code that denotes a L-value.
An R-value expression is an expression appearing in source code that denotes a value.
The L-value / R-value distinction originated with Strachey 1963.
For example in the following C++ code, array is a variable, array[3] is an L-value expression and i+j is an R-value expression. Note that the elements of the array are L-values not variables.
int array[10];
array[3] = i+j;
A common way to help define programming language semantics is to define denotations on expressions that conform to a grammar. A denotation can be given for both L-value expressions and R-value expressions.
In these terms, updating through a view is concerned with defining which RA expressions are L-value expressions (not R-value expressions) and giving denotations as L-values on them.