In this session, you learn how the introduction of assignments affects our notions of identity and change. In fact assignment poses new problems for deciding whether to expressions are the same. If one excludes assignments and one simply writes val X = E and val Y = E for some expression E. Then it's reasonable to assume that X and Y are the same. That is to say that we could also have written val X = E. And then instead of repeating E, we just right val Y = X. X is the same as E so we might as well use the value of X instead of E or so it goes. This property that we can do these changes in confidence is usually called referential transparency. Referential transparency means that our reference such as X is really the same as the thing it's bound to. So it doesn't matter whether you use X or the things it's defined as namely the expression if it comes down to the same thing. But once we allow assignments, things become more complicated. For instance, if now we would write val X = bank account Val, Y = bank account are X and Y is still the same? Well intuitively know because we have Created two different bank accounts, but according to our previous definition X and why would be the same. They have the same right hand side so we might as well right, val Y equals X. So what happens here while to respond to this question whether X and Y are the same, we should specify what is meant by the same. The precise meaning of being the same is defined by a property called operational equivalence. In a somewhat informal way this property is stated as follows. Suppose we have two definitions, X and Y. X and Y are operationally equivalent if no possible test can distinguish between them. So that begs the question, what is a possible test? So let's make that concrete to test whether to definitions X and Y are the same we must execute the definitions and then follow it by an arbitrary sequence of operations here called S. And that can involve both X and Y. And we observe the possible outcomes. Then we execute the definitions with another sequence S prime. That is the same as S but every occurrence of why is replaced by X. So instead of using why we use X in this new sequence here. If the results are different than the expressions X and Y are certainly different, it makes a difference whether I use X or Y in the sequence of operations. On the other hand, if all possible pairs of sequences S and S prime, produce the same result. Then I can't observe a difference and that means I have to conclude that X and Y are the same. Not that this is not a test, I can do mechanically, to be sure to observe a difference I just need a single sequence S that when I do the remaining here yields a different result, so that's easy. But on the other hand, to prove that to definitions are operational equivalents, I have to reason about all possible sequences of actions that follow the definitions and there are infinitely many of those. So I can't really do that in an experimental fashion. I have to find another way to prove that. So let's see based on these definitions, let's prove that these two bank accounts, X and Y are different. So let's see based on this definition, let's see whether the expressions, val X = bank account val Y = bank account defined values extent X and Y that are the same. Let's follow the definitions by a test sequence, let's say deposit 30 units into bank account X and withdraw 20 units from Y. So what you will get is a result of 30 in the first case and an error insufficient funds in the second case because Y was empty before the withdrawal. On the other hand, if we remain all occurrences of Y in the sequence with X, then what we would get is X withdraw 20. So we would get this sequence here and we would observe 30 after line three and 10 after line four. So the final results are different the result of this withdrawal operation and therefore we conclude that X and Y are not the same, that's the proof. On the other hand, if we define, val X = bank account, val Y = X, then no sequence of operations can distinguish between X and Y. So X and Y are the same in this case. One can do a formal proof of this statement by essentially formalizing the semantics of programming languages, but that's beyond the scope of this course. The preceding examples show that our model of computation by rewriting or by substitution cannot be used anymore. Indeed, according to the substitution model, one can always replace the name of a value by the expression that defines it. For instance, if we have these statements here, X = bank account val Y = X, then the X and the definition of why would be replaced by bank account. That's what the substitution model predicts, it says simplify this to a value. Well, an object reference is already a value and then replace the reference by the value that you find here. So the substitution model tells us that that rewrites to that and if you rewrite things and they're necessarily the same. But now we have seen that this change leads in fact to a different program. So it means the substitution model clearly is no longer valid if we add assignments. It's possible to rescue the situation to adapt the substitution model by introducing a store that essentially tracks all variable bindings that you have in your program. But then things become considerably more complicated. So we see that adding variables and beautiful state to functional programming gives us additional expressive power. But we pay for this with a loss of simple semantic foundations and also with the loss of reasoning capabilities. Because we have seen that the substitution model actually was used extensively improves about programs based on structural induction.
