Note that on line 4, the value to print is an invocation. This means that the “return value” of the invocation to “seven” will be printed. The following trace explains what happens when this code executes:
| comments | line# |
|
||
| 1 | pre |
|
||
| 2 | 4 | retinfo | On line 4, we cannot proceed to print anything until we know the “return value” of invoking “seven”. As a result, we are invoking “seven” first. Note that we now use “retinfo” instead of “retline#”. This is because just knowing which line to return to is no longer sufficient. We need to what else on a line needs to execute when we get back to a line. |
|
| 3 | 4: print (?) | The invocation (of “seven”) is replaced by a single question mark. The question mark is a place holder for the return value of invoking “seven”. When a return statement executes, it fill the place holder with an actual value. |
||
| 4 | 2 | 4: print (7) | When a return statement executes, we copy-and-paste the original “retinfo” cell (C3). Then the question mark is replaced by the value that is specified on the right hand side of the “return” statement. In this case, line 2 of the pseudocode returns a constant of 7, the question mark is replaced by 7. Note that we do not execute line 4 of the pseudocode at this point. We are merely resolving the value to print. |
|
| 5 | 3 | retinfo | The “retinfo” column is deallocated. However, line 4 of the pseudocode is now resolved, it is effectively as described in cell C4. |
|
| 6 | print 7 | 4 | After we return to line 4 (as indicated by column C), there is nothing else to resolve. As a result, we can now print the value of 7. In other words, we execute line 4 as described by cell C4 at this point of time. |
|
| 7 | post |
|
||
To summarize, the use of a “return value” necessitates a few changes from subroutine invocations before. First, instead of using a “retline#” column, we need to use a “retinfo” column. A “retline#” can only indicate a line number to continue execution. This is no longer sufficient because we need to return to the same line that has an “invoke”, and continue other pending operations on that line.
The content of the “retinfo” column is also different. Instead of just a line number, now it is the entire line (with the line number indicated). However, the “invoke” that is being executed is replaced by a single question mark. This question mark is a place holder for the return value of the invocation.
The execution of the invoked subroutine proceeds as before, until the “return” statement executes. A return statement has two operations to perform:
In essense, a “return” statement resolves an invocation to a particular value. It is important, however, not to execute or simplify the statement in the “retinfo” cell.
When a subroutine that contains a “return” statement ends at “end define sub”, we also need to do thing a little differently. Like before, we need to deallocate all the columns allocated for the invocation. However, to continue execution after the subroutine, we now utilize the to-be-deallocated “retinfo” column.
Before, we simply use “retline#” to tell us where to continue execution. Now, we have to use “retinfo”, which does not only tells us where to go (which line), but also the current state of that line. This means that the “retinfo” cell becomes the statement to execute after “end define sub”.