Solution: There is no problem with multiple interfaces because no code is associated with features listed in interfaces. Even if a method m is listed in two different interfaces, there is no problem. If the signatures of m are identical, then they represent the same method (and no conflicting bodies exist). Otherwise they represent different overloaded functions (and again there is no conflict). The only possible problem is if two interfaces give the same method m with the same parameter types and different return types. But in that case, this is simply a static error.

a) Describe in detail the effect of executing the Pascal assignment

	a[a[i]] := a[i] + 1
	

Solution: First a[i] is evaluated to get the integer, n, stored in a[i]. Then the location corresponding to a[n] is calculated and remembered. Then a[i] is evaluated again and the value is added to one, giving an integer value m (really n+1). That value is stored in the location of a[n].

	write(E); L := E; writeln(L);

Solution: The hint shows that the answer is no! a[a[i]] = a[2], so a[2] gets 2+1 = 3. But now the value of a[a[i]] is the value of a[a[2]] = a[3] which is 0. Thus write(E) gives 3, but writeln(L) gives 0.

c) What does this tell you about the validity of the axiomatic rule for assignment,{P [E / L]} L := E {P}, (e.g., if L = a[a[i]], E = a[i] + 1, and P is a[a[i]] = 3)? Suggest a restriction which makes it valid.

Solution: There are any number of restrictions that make the rule valid. The simplest, but most restrictive, is to say the rule is not valid with arrays. A less severe restriction is to say the rule is invalid if the left-hand side might be affected by the evaluation of E and the assignment. In the example above, the evaluation of E is fine, but the assignment itself changes the value of the left-hand side. a[i] = i++ is another problematic statement because a[i] before evaluating the right side will refer to a different location than a[i] after the evaluation of the right side. Thus the problem can arise from different aspects of the evaluation of E and assignment. A simpler to phrase restriction might be to only allow the rule to be applied when the subscript of an array on the left-hand side is a constant, though this is still pretty restrictive. Personally I'd probably restrict the subscript to not include references to the same array and not to allow any side effects that would change the value of the subscript.

{Precondition: n > 0}
   i <- n
   fact <- 1
   while i > 0 do
   {assert:  ...}
      fact <- fact * i
      i <- i - 1
   end while
{Postcondition:	fact = 1*2*...*n}

Note: If you prefer to use the weakest precondition rules in the text, be my guest, but I suspect you will find it easier to use those given in class instead.

Solution:

The key is to find the loop invariant. Note that it will have to be strong enough to prove the postcondition. Let's try:

   fact * i! = n! & i ≥ 0

Recall that the correctness rule for while loops is:

Since B is "i > 0", we must show that:

   {fact * i! = n! & i ≥ 0 & i > 0}
      fact <- fact * i
      i <- i - 1
   {fact * i! = n! & i ≥ 0}
   

Now we can use the assignment rule ({P[e/x]} x := e {P}) twice by working our way up the program:

   {fact * (i-1)! = n! & i -1 ≥ 0} 
      i <- i - 1 
   {fact * i! = n! & i ≥ 0}

and then

   {fact * i * (i-1)! = n! & i -1 ≥ 0} 
      fact <- fact * i 
   {fact * (i-1)! = n! & i -1 ≥ 0}
   

Note that the precondition of the last statement can be rewritten as:

   {fact * i! = n! & i  ≥ 1}

By Composition, we get:

   {fact * i ! = n! & i  ≥ 1} 
      fact <- fact * i;
      i <- i - 1 
   {fact * i! = n! & i ≥ 0}
   

But clearly, fact * i! = n! & i ≥ 0 & i > 0 implies fact * i ! = n! & i ≥ 1. Therefore by the consequence rule we get:

   {fact * i! = n! & i ≥ 0 & i > 0} 
      fact <- fact * i; 
      i <- i - 1 
   {fact * i! = n! & i ≥ 0}
   

Since this establishes that fact * i! = n! & i ≥ 0 is a loop invariant, the while rule implies:

   {fact * i! = n! & i ≥ 0}
      while i > 0 do  
        fact <- fact * i
        i <- i - 1
      end while
   {fact * i! = n! & i ≥ 0 & not(i > 0)}

Now i ≥ 0 & not(i > 0) implies i = 0 and therefore fact * i! = fact * 0! = fact.

Thus fact * i! = n! & i ≥ 0 & not(i > 0) implies fact = n!.

Again by the consequence rule (and our earlier deduction on pre- and post-conditions on the while loop) we can now deduce:

   {fact * i! = n! & i ≥ 0}
      while i > 0 do
         fact <- fact * i
         i <- i - 1
      end while
   {fact  = n!}
   

All we have to worry about now is taking care of the program before the while loop.

Thus if we can show:

   {n > 0}
      i <- n 
      fact <- 1
   {fact * i! = n! & i ≥ 0}

We can prove this last part as before by pushing the postcondition up through the assignment statements using the assignment rule as follows:

   {1 * i! = n! & i ≥ 0}
      fact <- 1 
   {fact * i! = n! & i ≥ 0}
   

   {1 * n! = n! & n ≥ 0}
      i <- n 
   {1 * i! = n! & i ≥ 0}
   

   {n ≥ 0} 
      i <- n 
   {1 * i! = n! & i ≥ 0}
   

   {n ≥ 0} 
      i <- n; fact <- 1 
   {fact * i! = n! & i ≥ 0}
   

We now notice that the precondition we were looking for was {n > 0}, but of course, n > 0 implies that n ≥ 0. Thus again by consequence, we get

   {n > 0} 
      i <- n; fact <- 1 
   {fact * i! = n! & i ≥ 0}
   

(This should make intuitive sense - if we strengthen the precondition, the postcondition should still be true.)

Using sequence, we can put this partial correctness assertion together with that for the while loop and obtain:

   {Precondition: n > 0}
      i <- n
      fact <- 1
      while i > 0 do
         fact <- fact * i
         i <- i - 1
      end while
	  {Postcondition:fact = 1*2*...*n}

as desired!

Solution omitted

Solution omitted