lec9b.eng.srt

1
00:00:15,840 --> 00:00:29,730
PROFESSOR: Well, I hope you appreciate that we have inducted you into some real magic, the magic of building languages, really building new languages.

2
00:00:29,730 --> 00:00:30,430
What have we looked at?

3
00:00:30,430 --> 00:00:42,360
We've looked at an Escher picture language: this language invented by Peter Henderson.

4
00:00:42,360 --> 00:00:46,260
We looked at digital logic language.

5
00:00:53,260 --> 00:00:53,570
Let's see.

6
00:00:53,570 --> 00:00:55,360
We've looked at the query language.

7
00:00:59,700 --> 00:01:08,250
And the thing you should realize is, even though these were toy examples, they really are the kernels of really useful things.

8
00:01:08,250 --> 00:01:23,300
So, for instance, the Escher picture language was taken by Henry Wu, who's a student at MIT, and developed into a real language for laying out PC boards based just on extending those structures.

9
00:01:23,300 --> 00:01:33,460
And the digital logic language, Jerry mentioned when he showed it to you, was really extended to be used as the basis for a simulator that was used to design a real computer.

10
00:01:33,460 --> 00:01:37,510
And the query language, of course, is kind of the germ of prologue.

11
00:01:37,510 --> 00:01:41,080
So we built all of these languages, they're all based on LISP.

12
00:01:43,630 --> 00:01:48,820
A lot of people ask what particular problems is LISP good for solving for?

13
00:01:48,820 --> 00:02:01,470
The answer is LISP is not good for solving any particular problems. What LISP is good for is constructing within it the right language to solve the problems you want to solve, and that's how you should think about it.

14
00:02:01,470 --> 00:02:04,326
So all of these languages were based on LISP.

15
00:02:04,326 --> 00:02:07,270
Now, what's LISP based on?

16
00:02:07,270 --> 00:02:07,920
Where's that come from?

17
00:02:07,920 --> 00:02:09,400
Well, we looked at that too.

18
00:02:12,740 --> 00:02:25,810
We looked at the meta-circular evaluator and said well, LISP is based on LISP.

19
00:02:25,810 --> 00:02:29,950
And when we start looking at that, we've got to do some real magic, right?

20
00:02:29,950 --> 00:02:31,660
So what does that mean, right?

21
00:02:31,660 --> 00:02:47,470
Why operators, and fixed points, and the idea that what this means is that LISP is somehow the fixed-point equation for this funny set of things which are defined in terms of themselves.

22
00:02:47,470 --> 00:02:49,070
Now, it's real magic.

23
00:02:49,070 --> 00:02:54,250
Well, today, for a final piece of magic, we're going to make all the magic go away.

24
00:03:06,430 --> 00:03:09,770
We already know how to do that.

25
00:03:09,770 --> 00:03:15,500
The idea is, we're going to take the register machine architecture and show how to implement LISP on terms of that.

26
00:03:15,500 --> 00:03:24,800
And, remember, the idea of the register machine is that there's a fixed and finite part of the machine.

27
00:03:24,800 --> 00:03:30,510
There's a finite-state controller, which does some particular thing with a particular amount of hardware.

28
00:03:30,510 --> 00:03:33,550
There are particular data paths: the operation the machine does.

29
00:03:33,550 --> 00:03:42,060
And then, in order to implement recursion and sustain the illusion of infinity, there's some large amount of memory, which is the stack.

30
00:03:42,060 --> 00:03:49,850
So, if we implement LISP in terms of a register machine, then everything ought to become, at this point, completely concrete.

31
00:03:49,850 --> 00:03:51,650
All the magic should go away.

32
00:03:51,650 --> 00:04:04,720
And, by the end of this talk, I want you get the feeling that, as opposed to this very mysterious meta-circular evaluator, that a LISP evaluator really is something that's concrete enough that you can hold in the palm of your hand.

33
00:04:04,720 --> 00:04:09,546
You should be able to imagine holding a LISP interpreter there.

34
00:04:09,546 --> 00:04:10,950
All right, how are we going to do this?

35
00:04:10,950 --> 00:04:13,960
We already have all the ingredients.

36
00:04:13,960 --> 00:04:28,210
See, what you learned last time from Jerry is how to take any particular couple of LISP procedures and hand-translate them into something that runs on a register machine.

37
00:04:28,210 --> 00:04:39,120
So, to implement all of LISP on a register machine, all we have to do is take the particular procedures that are the meta-circular evaluator and hand-translate them for a register machine.

38
00:04:39,120 --> 00:04:42,320
And that does all of LISP, right?

39
00:04:42,320 --> 00:04:45,380
So, in principle, we already know how to do this.

40
00:04:45,380 --> 00:04:54,670
And, indeed, it's going to be no different, in kind, from translating, say, recursive factorial or recursive Fibonacci.

41
00:04:54,670 --> 00:04:56,840
It's just bigger and there's more of it.

42
00:04:56,840 --> 00:05:01,730
So it'd just be more details, but nothing really conceptually new.

43
00:05:01,730 --> 00:05:14,810
All right, also, when we've done that, and the thing is completely explicit, and we see how to implement LISP in terms of the actual sequential register operations, that's going to be our final most explicit model of LISP in this course.

44
00:05:14,810 --> 00:05:16,950
And, remember, that's a progression through this course.

45
00:05:16,950 --> 00:05:20,370
We started out with substitution, which is sort of like algebra.

46
00:05:20,370 --> 00:05:26,390
And then we went to the environment model, which talked about the actual frames and how they got linked together.

47
00:05:26,390 --> 00:05:31,080
And then we made that more concrete in the meta-circular evaluator.

48
00:05:31,080 --> 00:05:34,360
There are things the meta-circular evaluator doesn't tell us.

49
00:05:34,360 --> 00:05:36,090
You should realize that.

50
00:05:36,090 --> 00:05:47,210
For instance, it left unanswered the question of how a procedure, like recursive factorial here , somehow takes space that grows.

51
00:05:47,210 --> 00:05:56,760
On the other hand, a procedure which also looks syntactically recursive, called fact-iter, somehow doesn't take space.

52
00:05:56,760 --> 00:06:01,960
We justify that it doesn't need to take space by showing the substitution model.

53
00:06:01,960 --> 00:06:12,520
But we didn't really say how it happens that the machine manages to do that, that that has to do with the details of how arguments are passed to procedures.

54
00:06:12,520 --> 00:06:23,510
And that's the thing we didn't see in the meta-circular evaluator precisely because the way arguments got passed to procedures in this LISP depended on the way arguments got passed to procedures in this LISP.

55
00:06:26,070 --> 00:06:30,740
But, now, that's going to become extremely explicit.

56
00:06:30,740 --> 00:06:31,230
OK.

57
00:06:31,230 --> 00:06:43,250
Well, before going on to the evaluator, let me just give you a sense of what a whole LISP system looks like so you can see the parts we're going to talk about and the parts we're not going to talk about.

58
00:06:43,250 --> 00:06:52,525
Let's see, over here is a happy LISP user, and the LISP user is talking to something called the reader.

59
00:07:00,360 --> 00:07:19,210
The reader's job in life is to take characters from the user and turn them into data structures in something called a list structure memory.

60
00:07:29,783 --> 00:07:42,340
All right, so the reader is going to take symbols, parentheses, and A's and B's, and ones and threes that you type in, and turn these into actual list structure: pairs, and pointers, and things.

61
00:07:42,340 --> 00:07:45,850
And so, by the time evaluator is going, there are no characters in the world.

62
00:07:45,850 --> 00:07:56,280
And, of course, in more modern list systems, there's sort of a big morass here that might sit between the user and the reader: Windows systems, and top levels, and mice, and all kinds of things.

63
00:07:56,280 --> 00:07:59,590
But conceptually, characters are coming in.

64
00:07:59,590 --> 00:08:17,090
All right, the reader transforms these into pointers to stuff in this memory, and that's what the evaluator sees, OK?

65
00:08:17,090 --> 00:08:19,780
The evaluator has a bunch of helpers.

66
00:08:19,780 --> 00:08:23,080
It has all possible primitive operators you might want.

67
00:08:23,080 --> 00:08:35,960
So there's a completely separate box, a floating point unit, or all sorts of things, which do the primitive operators.

68
00:08:35,960 --> 00:08:42,080
And, if you want more special primitives, you build more primitive operators, but they're separate from the evaluator.

69
00:08:42,080 --> 00:08:47,400
The evaluator finally gets an answer and communicates that to the printer.

70
00:08:50,780 --> 00:09:05,540
And now, the printer's job in life is to take this list structure coming from the evaluator, and turn it back into characters, and communicate them to the user through whatever interface there is.

71
00:09:08,050 --> 00:09:08,810
OK.

72
00:09:08,810 --> 00:09:12,670
Well, today, what we're going to talk about is this evaluator.

73
00:09:12,670 --> 00:09:19,440
The primitive operators have nothing particular to do with LISP, they're however you like to implement primitive operations.

74
00:09:19,440 --> 00:09:24,420
The reader and printer are actually complicated, but we're not going to talk about them.

75
00:09:24,420 --> 00:09:29,900
They sort of have to do with details of how you might build up list structure from characters.

76
00:09:29,900 --> 00:09:32,490
So that is a long story, but we're not going to talk about it.

77
00:09:32,490 --> 00:09:36,930
The list structure memory, we'll talk about next time.

78
00:09:36,930 --> 00:09:46,295
So, pretty much, except for the details of reading and printing, the only mystery that's going to be left after you see the evaluator is how you build list structure on conventional memories.

79
00:09:46,295 --> 00:09:50,580
But we'll worry about that next time too.

80
00:09:50,580 --> 00:09:51,830
OK.

81
00:09:53,350 --> 00:09:56,110
Well, let's start talking about the evaluator.

82
00:09:56,110 --> 00:10:01,120
The one that we're going to show you, of course, is not, I think, nothing special about it.

83
00:10:01,120 --> 00:10:04,810
It's just a particular register machine that runs LISP.

84
00:10:04,810 --> 00:10:09,890
And it has seven registers, and here are the seven registers.

85
00:10:09,890 --> 00:10:18,370
There's a register, called EXP, and its job is to hold the expression to be evaluated.

86
00:10:18,370 --> 00:10:26,550
And by that, I mean it's going to hold a pointer to someplace in list structure memory that holds the expression to be evaluated.

87
00:10:26,550 --> 00:10:34,070
There's a register, called ENV, which holds the environment in which this expression is to be evaluated.

88
00:10:34,070 --> 00:10:34,940
And, again, I made a pointer.

89
00:10:34,940 --> 00:10:38,240
The environment is some data structure.

90
00:10:38,240 --> 00:10:44,630
There's a register, called FUN, which will hold the procedure to be applied when you go to apply a procedure.

91
00:10:44,630 --> 00:10:50,630
A register, called ARGL, which wants the list of evaluated arguments.

92
00:10:50,630 --> 00:10:53,140
What you can start seeing here is the basic structure of the evaluator.

93
00:10:53,140 --> 00:10:54,490
Remember how evaluators work.

94
00:10:54,490 --> 00:11:03,480
There's a piece that takes expressions and environments, and there's a piece that takes functions, or procedures and arguments.

95
00:11:03,480 --> 00:11:07,740
And going back and forth around here is the eval/apply loop.

96
00:11:07,740 --> 00:11:10,270
So those are the basic pieces of the eval and apply.

97
00:11:10,270 --> 00:11:11,610
Then there's some other things, there's continue.

98
00:11:11,610 --> 00:11:19,000
You just saw before how the continue register is used to implement recursion and stack discipline.

99
00:11:19,000 --> 00:11:24,190
There's a register that's going to hold the result of some evaluation.

100
00:11:24,190 --> 00:11:37,150
And then, besides that, there's one temporary register, called UNEV, which typically, in the evaluator, is going to be used to hold temporary pieces of the expression you're working on, which you haven't gotten around to evaluate yet, right?

101
00:11:37,150 --> 00:11:40,646
So there's my machine: a seven-register machine.

102
00:11:40,646 --> 00:11:48,480
And, of course, you might want to make a machine with a lot more registers to get better performance, but this is just a tiny, minimal one.

103
00:11:48,480 --> 00:11:49,780
Well, how about the data paths?

104
00:11:49,780 --> 00:11:55,100
This machine has a lot of special operations for LISP.

105
00:11:55,100 --> 00:12:00,120
So, here are some typical data paths.

106
00:12:00,120 --> 00:12:06,710
A typical one might be, oh, assign to the VAL register the contents of the EXP register.

107
00:12:06,710 --> 00:12:11,900
In terms of those diagrams you saw, that's a little button on some arrow.

108
00:12:11,900 --> 00:12:14,040
Here's a more complicated one.

109
00:12:14,040 --> 00:12:23,850
It says branch, if the thing in the expression register is a conditional to some label here, called the ev-conditional.

110
00:12:23,850 --> 00:12:26,230
And you can imagine this implemented in a lot of different ways.

111
00:12:26,230 --> 00:12:36,610
You might imagine this conditional test as a special purpose sub-routine, and conditional might be represented as some data abstraction that you don't care about at this level of detail.

112
00:12:36,610 --> 00:12:37,980
So that might be done as a sub-routine.

113
00:12:37,980 --> 00:12:45,350
This might be a machine with hardware-types, and conditional might be testing some bits for a particular code.

114
00:12:45,350 --> 00:12:50,190
There are all sorts of ways that's beneath the level of abstraction we're looking at.

115
00:12:50,190 --> 00:12:56,840
Another kind of operation, and there are a lot of different operations assigned to EXP, the first clause of what's in EXP.

116
00:12:56,840 --> 00:12:59,260
This might be part of processing a conditional.

117
00:12:59,260 --> 00:13:04,470
And, again, first clause is some selector whose details we don't care about.

118
00:13:04,470 --> 00:13:12,170
And you can, again, imagine that as a sub-routine which'll do some list operations, or you can imagine that as something that's built directly into hardware.

119
00:13:12,170 --> 00:13:19,740
The reason I keep saying you can imagine it built directly into hardware is even though there are a lot of operations, there are still a fixed number of them.

120
00:13:19,740 --> 00:13:22,370
I forget how many, maybe 150.

121
00:13:22,370 --> 00:13:26,400
So, it's plausible to think of building these directly into hardware.

122
00:13:26,400 --> 00:13:28,500
Here's a more complicated one.

123
00:13:28,500 --> 00:13:31,710
You can see this has to do with looking up the values of variables.

124
00:13:31,710 --> 00:13:42,850
It says assign to the VAL register the result of looking up the variable value of some particular expression, which, in this case, is supposed to be a variable in some environment.

125
00:13:42,850 --> 00:13:52,240
And this'll be some operation that searches through the environment structure, however it is represented, and goes and looks up that variable.

126
00:13:52,240 --> 00:13:55,790
And, again, that's below the level of detail that we're thinking about.

127
00:13:55,790 --> 00:14:00,380
This has to do with the details of the data structures for representing environments.

128
00:14:00,380 --> 00:14:05,940
But, anyway, there is this fixed and finite number of operations in the register machine.

129
00:14:08,500 --> 00:14:11,720
Well, what's its overall structure?

130
00:14:11,720 --> 00:14:14,930
Those are some typical operations.

131
00:14:14,930 --> 00:14:22,890
Remember what we have to do, we have to take the meta-circular evaluator-- and here's a piece of the meta-circular evaluator.

132
00:14:22,890 --> 00:14:28,310
This is the one using abstract syntax that's in the book.

133
00:14:28,310 --> 00:14:33,500
It's a little bit different from the one that Jerry shows you.

134
00:14:33,500 --> 00:14:48,560
And the main thing to remember about the evaluator is that it's doing some sort of case analysis on the kinds of expressions: so if it's either self-evaluated, or quoted, or whatever else.

135
00:14:48,560 --> 00:14:55,750
And then, in the general case where the expression it's looking at is an application, there's some tricky recursions going on.

136
00:14:55,750 --> 00:15:05,880
First of all, eval has to call itself both to evaluate the operator and to evaluate all the operands.

137
00:15:05,880 --> 00:15:12,270
So there's this sort of red recursion of values walking down the tree that's really the easy recursion.

138
00:15:12,270 --> 00:15:14,750
That's just a val walking down this tree of expressions.

139
00:15:14,750 --> 00:15:16,600
Then, in the evaluator, there's a hard recursion.

140
00:15:16,600 --> 00:15:18,200
There's the red to green.

141
00:15:18,200 --> 00:15:19,450
Eval calls apply.

142
00:15:22,470 --> 00:15:30,370
That's the case where evaluating a procedure or argument reduces to applying the procedure to the list of arguments.

143
00:15:30,370 --> 00:15:31,700
And then, apply comes over here.

144
00:15:34,770 --> 00:15:44,560
Apply takes a procedure and arguments and, in the general case where there's a compound procedure, apply goes around and green calls red.

145
00:15:44,560 --> 00:15:48,170
Apply comes around and calls eval again.

146
00:15:48,170 --> 00:15:56,605
Eval's the body of the procedure in the result of extending the environment with the parameters of the procedure by binding the arguments.

147
00:15:59,620 --> 00:16:05,980
Except in the primitive case, where it just calls something else primitive-apply, which is not really the business of the evaluator.

148
00:16:05,980 --> 00:16:17,186
So this sort of red to green, to red to green, that's the eval/apply loop, and that's the thing that we're going to want to see in the evaluator.

149
00:16:19,840 --> 00:16:19,970
All right.

150
00:16:19,970 --> 00:16:27,470
Well, it won't surprise you at all that the two big pieces of this evaluator correspond to eval and apply.

151
00:16:27,470 --> 00:16:32,110
There's a piece called eval-dispatch, and a piece called apply-dispatch.

152
00:16:32,110 --> 00:16:41,870
And, before we get into the details of the code, the way to understand this is to think, again, in terms of these pieces of the evaluator having contracts with the rest of the world.

153
00:16:41,870 --> 00:16:45,780
What do they do from the outside before getting into the grungy details?

154
00:16:45,780 --> 00:16:51,300
Well, the contract for eval-dispatch-- remember, it corresponds to eval.

155
00:16:51,300 --> 00:16:54,100
It's got to evaluate an expression in an environment.

156
00:16:54,100 --> 00:17:03,640
So, in particular, what this one is going to do, eval-dispatch will assume that, when you call it, that the expression you want to evaluate is in the EXP register.

157
00:17:03,640 --> 00:17:09,569
The environment in which you want the evaluation to take place is in the ENV register.

158
00:17:09,569 --> 00:17:13,880
And continue tells you the place where the machine should go next when the evaluation is done.

159
00:17:17,440 --> 00:17:26,619
Eval-dispatch's contract is that it'll actually perform that evaluation, and, at the end of which, it'll end up at the place specified by continue.

160
00:17:26,619 --> 00:17:29,950
The result of the evaluation will be in the VAL register.

161
00:17:29,950 --> 00:17:35,230
And it just warns you, it makes no promises about what happens to the registers.

162
00:17:35,230 --> 00:17:37,490
All other registers might be destroyed.

163
00:17:37,490 --> 00:17:41,790
So, there's one piece, OK?

164
00:17:41,790 --> 00:17:54,540
Together, the pieces, apply-dispatch that corresponds to apply, it's got to apply a procedure to some arguments, so it assumes that this register, ARGL, contains a list of the evaluated arguments.

165
00:17:54,540 --> 00:17:57,220
FUN contains the procedure.

166
00:17:57,220 --> 00:18:01,055
Those correspond to the arguments to the apply procedure in the meta-circular evaluator.

167
00:18:03,970 --> 00:18:21,840
And apply, in this particular evaluator, we're going to use a discipline which says the place the machine should go to next when apply is done is, at the moment apply-dispatch is called at the top of the stack, that's just discipline for the way this particular machine's organized.

168
00:18:21,840 --> 00:18:23,950
And now apply's contract is given all that.

169
00:18:23,950 --> 00:18:25,540
It'll perform the application.

170
00:18:25,540 --> 00:18:28,890
The result of that application will end up in VAL.

171
00:18:28,890 --> 00:18:31,120
The stack will be popped.

172
00:18:31,120 --> 00:18:35,110
And, again, the contents of all the other registers may be destroyed, all right?

173
00:18:35,110 --> 00:18:39,760
So that's the basic organization of this machine.

174
00:18:39,760 --> 00:18:42,700
Let's break for a little bit and see if there are any questions, and then we'll do a real example.

175
00:19:47,850 --> 00:20:03,400
Well, let's take the register machine now, and actually step through, and really, in real detail, so you see completely concrete how some expressions are evaluated, all right?

176
00:20:03,400 --> 00:20:06,435
So, let's start with a very simple expression.

177
00:20:09,620 --> 00:20:13,320
Let's evaluate the expression 1.

178
00:20:18,880 --> 00:20:23,085
And we need an environment, so let's imagine that somewhere there's an environment, we'll call it E,0.

179
00:20:30,260 --> 00:20:38,360
And just, since we'll use these later, we obviously don't really need anything to evaluate 1.

180
00:20:38,360 --> 00:20:49,140
But, just for reference later, let's assume that E,0 has in it an X that's bound to 3 and a Y that's bound to 4, OK?

181
00:20:49,140 --> 00:21:03,560
And now what we're going to do is we're going to evaluate 1 in this environment, and so the ENV register has a pointer to this environment, E,0, all right?

182
00:21:03,560 --> 00:21:05,650
So let's watch that thing go.

183
00:21:05,650 --> 00:21:08,260
What I'm going to do is step through the code.

184
00:21:08,260 --> 00:21:10,080
And, let's see, I'll be the controller.

185
00:21:10,080 --> 00:21:16,830
And now what I need, since this gets rather complicated, is a very little execution unit.

186
00:21:16,830 --> 00:21:22,624
So here's the execution unit, OK?

187
00:21:22,624 --> 00:21:23,874
OK.

188
00:21:27,088 --> 00:21:28,590
OK.

189
00:21:28,590 --> 00:21:30,690
All right, now we're going to start.

190
00:21:30,690 --> 00:21:33,660
We're going to start the machine at eval-dispatch, right?

191
00:21:33,660 --> 00:21:36,120
That's the beginning of this.

192
00:21:36,120 --> 00:21:42,010
Eval-dispatch is going to look at the expression in dispatch, just like eval where we look at the very first thing.

193
00:21:42,010 --> 00:21:47,950
We branch on whether or not this expression is self-evaluating.

194
00:21:47,950 --> 00:21:57,040
Self-evaluating is some abstraction we put into the machine-- it's going to be true for numbers-- to a place called ev-self-eval, right?

195
00:21:57,040 --> 00:22:02,780
So me, being the controller, looks at ev-self-eval, so we'll go over to there.

196
00:22:02,780 --> 00:22:15,220
Ev-self-eval says fine, assign to val whatever is in the expression unit, OK?

197
00:22:15,220 --> 00:22:32,050
And I have a bug because what I didn't do when I initialized this machine is also say what's supposed to happen when it's done, so I should have started out the machine with done being in the continue register, OK?

198
00:22:32,050 --> 00:22:33,640
So we assign to VAL.

199
00:22:33,640 --> 00:22:40,000
And now go to fetch of continue, and now change-- OK.

200
00:22:40,000 --> 00:22:42,160
OK, let's try something harder.

201
00:22:42,160 --> 00:22:56,710
Let's reset the machine here, and we'll put in the expression register, X, OK?

202
00:22:56,710 --> 00:22:59,610
Start again at eval-dispatch.

203
00:22:59,610 --> 00:23:01,690
Check, is it self-evaluating?

204
00:23:01,690 --> 00:23:02,650
No.

205
00:23:02,650 --> 00:23:04,630
Is it a variable?

206
00:23:04,630 --> 00:23:05,560
Yes.

207
00:23:05,560 --> 00:23:08,380
We go off to ev-variable.

208
00:23:08,380 --> 00:23:21,620
It says assign to VAL, look up the variable value in the expression register, OK?

209
00:23:21,620 --> 00:23:23,625
Go to fetch of continue.

210
00:23:23,625 --> 00:23:24,875
PROFESSOR: Done.

211
00:23:27,252 --> 00:23:28,950
PROFESSOR: OK.

212
00:23:28,950 --> 00:23:29,430
All right.

213
00:23:29,430 --> 00:23:31,330
Well, that's the basic idea.

214
00:23:31,330 --> 00:23:32,920
That's a simple operation of the machine.

215
00:23:32,920 --> 00:23:36,070
Now, let's actually do something a little bit more interesting.

216
00:23:36,070 --> 00:23:49,678
Let's look at the expression the sum of x and y.

217
00:23:49,678 --> 00:23:50,130
OK.

218
00:23:50,130 --> 00:23:57,100
And now we'll see how you start unrolling these expression trees, OK?

219
00:23:57,100 --> 00:24:00,645
Well, start again at eval-dispatch, all right?

220
00:24:04,610 --> 00:24:06,060
Self-evaluating?

221
00:24:06,060 --> 00:24:06,810
No.

222
00:24:06,810 --> 00:24:07,280
Variable?

223
00:24:07,280 --> 00:24:07,850
No.

224
00:24:07,850 --> 00:24:13,260
All the other special forms which I didn't write down, like quote, and lambda, and set, and whatever, it's none of those.

225
00:24:13,260 --> 00:24:19,970
It turns out to be an application, so we go off to ev-application, OK?

226
00:24:19,970 --> 00:24:25,580
Ev-application, remember what it's going to do overall.

227
00:24:25,580 --> 00:24:28,310
It is going to evaluate the operator.

228
00:24:28,310 --> 00:24:35,060
It's going to evaluate the arguments, and then it's going to go apply them.

229
00:24:35,060 --> 00:24:55,340
So, before we start, since we're being very literal, we'd better remember that, somewhere in this environment, it's linked to another environment in which plus is bound to the primitive procedure plus before we get an unknown variable in our machine.

230
00:24:55,340 --> 00:24:56,590
OK, so we're at ev-application.

231
00:24:59,850 --> 00:25:07,920
OK, assign to UNEV the operands of what's in the expression register, OK?

232
00:25:07,920 --> 00:25:09,230
Those are the operands.

233
00:25:09,230 --> 00:25:12,916
UNEV's a temporary register where we're going to save them.

234
00:25:12,916 --> 00:25:13,860
PROFESSOR: I'm assigning.

235
00:25:13,860 --> 00:25:18,070
PROFESSOR: Assign to x the operator.

236
00:25:18,070 --> 00:25:25,820
Now, notice we've destroyed that expression in x, but the piece that we need is now in UNEV. OK.

237
00:25:25,820 --> 00:25:28,750
Now, we're going to get set up to recursively evaluate the operator.

238
00:25:28,750 --> 00:25:31,565
Save the continue register on the stack.

239
00:25:34,870 --> 00:25:36,120
Save the environment.

240
00:25:40,520 --> 00:25:54,460
Save UNEV. OK, assign to continue a label called eval-args.

241
00:26:01,400 --> 00:26:01,980
Now, what have we done?

242
00:26:01,980 --> 00:26:04,380
We've set up for a recursive call.

243
00:26:04,380 --> 00:26:06,280
We're about to go to eval-dispatch.

244
00:26:06,280 --> 00:26:10,230
We've set up for a recursive call to eval-dispatch.

245
00:26:10,230 --> 00:26:11,020
What did we do?

246
00:26:11,020 --> 00:26:27,120
We took the things we're going to need later, those operands that were in UNEV; the environment in which we're going to eventually have to, maybe, evaluate those operands; the place we eventually want to go to, which, in this case, was done; we've saved them on the stack.

247
00:26:27,120 --> 00:26:33,550
The reason we saved them on the stack is because eval-dispatch makes no promises about what registers it may destroy.

248
00:26:33,550 --> 00:26:35,020
So all that stuff is saved on the stack.

249
00:26:35,020 --> 00:26:37,380
Now, we've set up eval-dispatch's contract.

250
00:26:37,380 --> 00:26:47,600
There's a new expression, which is the operator plus; a new environment, although, in this case, it's the same one; and a new place to go to when you're done, which is eval-args.

251
00:26:47,600 --> 00:26:48,130
So that's set up.

252
00:26:48,130 --> 00:26:50,890
Now, we're going to go off to eval-dispatch.

253
00:26:50,890 --> 00:26:53,090
Here we are back at eval-dispatch.

254
00:26:53,090 --> 00:26:54,490
It's not self-evaluating.

255
00:26:54,490 --> 00:27:00,260
Oh, it's a variable, so we'd better go off to ev-variable, right?

256
00:27:00,260 --> 00:27:02,880
Ev-variable is assigned to VAL.

257
00:27:02,880 --> 00:27:08,770
Look up the variable value of the expression, OK?

258
00:27:08,770 --> 00:27:13,000
So VAL is the primitive procedure plus, OK?

259
00:27:13,000 --> 00:27:15,020
And go to fetch of continue.

260
00:27:15,020 --> 00:27:15,660
PROFESSOR: Eval-args.

261
00:27:15,660 --> 00:27:19,340
PROFESSOR: Right, which is now eval-args not done.

262
00:27:19,340 --> 00:27:23,210
So we come back here at eval-args, and what do we do?

263
00:27:23,210 --> 00:27:32,900
We're going to restore the stuff that we saved, so we restore UNEV. And notice, there, it wasn't necessary, although, in general, it would be.

264
00:27:32,900 --> 00:27:35,430
It might be some arbitrary evaluation that happened.

265
00:27:35,430 --> 00:27:51,900
We restore ENV. OK, we assign to FUN fetch of VAL.

266
00:27:58,620 --> 00:28:04,340
OK, now, we're going to go off and start evaluating some arguments.

267
00:28:04,340 --> 00:28:10,165
Well, first thing we'd better do is save FUN because some arbitrary stuff might happen in that evaluation.

268
00:28:15,330 --> 00:28:25,460
We initialize the argument list. Assign to argl an empty argument list, and go to eval-arg-loop, OK?

269
00:28:25,460 --> 00:28:38,090
At eval-arg-loop, the idea of this is we're going to evaluate the pieces of the expressions that are in UNEV, one by one, and move them from unevaluated in UNEV to evaluated in the arg list, OK?

270
00:28:38,090 --> 00:28:39,340
So we save argl.

271
00:28:43,950 --> 00:28:53,960
We assign to x the first operand of the stuff in UNEV.

272
00:28:53,960 --> 00:28:55,890
Now, we check and see if that was the last operand.

273
00:28:55,890 --> 00:28:59,190
In this case, it is not, all right?

274
00:28:59,190 --> 00:29:01,235
So we save the environment.

275
00:29:09,170 --> 00:29:13,500
We save UNEV because those are all things we might need later.

276
00:29:13,500 --> 00:29:15,800
We're going to need the environment to do some more evaluations.

277
00:29:15,800 --> 00:29:20,340
We're going to need UNEV to look at what the rest of those arguments were.

278
00:29:20,340 --> 00:29:24,040
We're going to assign continue a place called accumulate-args, or accumulate-arg.

279
00:29:30,898 --> 00:29:36,810
OK, now, we've set up for another call to eval-dispatch, OK?

280
00:29:36,810 --> 00:29:41,090
All right, now, let me short-circuit this so we don't go through the details of eval-dispatch.

281
00:29:41,090 --> 00:29:51,320
Eval-dispatch's contract says I'm going to end up, the world will end up, with the value of evaluating this expression in this environment in the VAL register, and I'll end up there.

282
00:29:51,320 --> 00:29:58,010
So we short-circuit all of this, and a 3 ends up in VAL.

283
00:29:58,010 --> 00:30:02,110
And, when we return from eval-dispatch, we're going to return to accumulate-arg.

284
00:30:02,110 --> 00:30:03,555
PROFESSOR: Accumulate-arg.

285
00:30:03,555 --> 00:30:08,720
PROFESSOR: With 3 in the VAL register, OK?

286
00:30:08,720 --> 00:30:10,650
So that short-circuited that evaluation.

287
00:30:10,650 --> 00:30:11,320
Now, what do we do?

288
00:30:11,320 --> 00:30:28,650
We're going to go back and look at the rest of the arguments, so we restore UNEV. We restore ENV. We restore argl.

289
00:30:28,650 --> 00:30:29,170
One thing.

290
00:30:29,170 --> 00:30:31,290
PROFESSOR: Oops! Parity error.

291
00:30:31,290 --> 00:30:33,465
[LAUGHTER]

292
00:30:33,465 --> 00:30:34,905
PROFESSOR: Restore argl.

293
00:30:41,650 --> 00:30:42,900
PROFESSOR: OK.

294
00:30:45,570 --> 00:30:53,130
OK, we assign to argl consing on fetch of the value register to what's in argl.

295
00:30:58,985 --> 00:31:11,516
OK, we assign to UNEV the rest of the operands in fetch of UNEV, and we go back to eval-arg-loop.

296
00:31:11,516 --> 00:31:12,280
PROFESSOR: Eval-arg-loop.

297
00:31:12,280 --> 00:31:13,530
PROFESSOR: OK.

298
00:31:15,880 --> 00:31:19,340
Now, we're about to do the next argument, so the first thing we do is save argl.

299
00:31:25,400 --> 00:31:37,140
OK, we assign to x the first operand of fetch of UNEV. OK, we test and see if that's the last operand.

300
00:31:37,140 --> 00:31:47,446
In this case, it is, so we're going to go to a special place that says evaluate the last argument because, notice, after evaluating the argument, we don't need the environment any more.

301
00:31:47,446 --> 00:31:50,250
That's going to be the difference.

302
00:31:50,250 --> 00:32:06,900
So here, at eval-last-arg, which is assigned to accumulate-last-arg, now, we're set up again for eval-dispatch.

303
00:32:06,900 --> 00:32:08,620
We've got a place to go to when we're done.

304
00:32:08,620 --> 00:32:09,840
We've got an expression.

305
00:32:09,840 --> 00:32:11,330
We've got an environment.

306
00:32:11,330 --> 00:32:14,370
OK, so we'll short-circuit the call to eval-dispatch.

307
00:32:14,370 --> 00:32:21,060
And what'll happen is there's a y there, it's 4 in that environment, so VAL will end up with 4 in it.

308
00:32:21,060 --> 00:32:25,450
And, then, we're going to end up at accumulate-last-arg, OK?

309
00:32:25,450 --> 00:32:30,150
So, at accumulate-last-arg, we restore argl.

310
00:32:41,490 --> 00:32:49,850
We assign to argl cons of fetch of the new value onto it, so we cons a 4 onto that.

311
00:32:49,850 --> 00:32:53,446
We restore what was saved in the function register.

312
00:32:53,446 --> 00:32:59,420
And notice, in this case, it had not been destroyed, but, in general, it will be.

313
00:32:59,420 --> 00:33:02,850
And now, we're ready to go off to apply-dispatch, all right?

314
00:33:02,850 --> 00:33:04,510
So we've just gone through the eval.

315
00:33:04,510 --> 00:33:09,580
We evaluated the argument, the operator, and the arguments, and now, we're about to apply them.

316
00:33:09,580 --> 00:33:17,481
So we come off to apply-dispatch here, OK?

317
00:33:17,481 --> 00:33:23,450
We come off to apply-dispatch, and we're going to check whether it's a primitive or a compound procedure.

318
00:33:23,450 --> 00:33:24,116
PROFESSOR: Yes.

319
00:33:24,116 --> 00:33:24,830
PROFESSOR: All right.

320
00:33:24,830 --> 00:33:29,790
So, in this case, it's a primitive procedure, and we go off to primitive-apply.

321
00:33:29,790 --> 00:33:40,940
So we go off to primitive-apply, and it says assign to VAL the result of applying primitive procedure of the function to the argument list.

322
00:33:40,940 --> 00:33:42,540
PROFESSOR: I don't know how to add.

323
00:33:42,540 --> 00:33:43,995
I'm just an execution unit.

324
00:33:43,995 --> 00:33:45,350
PROFESSOR: Well, I don't know how to add either.

325
00:33:45,350 --> 00:33:48,360
I'm just the evaluator, so we need a primitive operator.

326
00:33:48,360 --> 00:33:52,605
Let's see, so the primitive operator, what's the sum of 3 and 4?

327
00:33:52,605 --> 00:33:53,205
AUDIENCE: 7.

328
00:33:53,205 --> 00:33:54,580
PROFESSOR: OK, 7.

329
00:33:54,580 --> 00:33:55,999
PROFESSOR: Thank you.

330
00:33:58,837 --> 00:34:12,900
PROFESSOR: Now, we restore continue, and we go to fetch of continue.

331
00:34:12,900 --> 00:34:13,880
PROFESSOR: Done.

332
00:34:13,880 --> 00:34:14,929
PROFESSOR: OK.

333
00:34:14,929 --> 00:34:18,659
Well, that was in as much detail as you will ever see.

334
00:34:18,659 --> 00:34:21,590
We'll never do it in as much detail again.

335
00:34:21,590 --> 00:34:29,780
One very important thing to notice is that we just executed a recursive procedure, right?

336
00:34:29,780 --> 00:34:33,070
This whole thing, we used a stack and the evaluator was recursive.

337
00:34:33,070 --> 00:34:42,150
A lot of people think the reason that you need a stack and recursion in an evaluator is because you might be evaluating recursive procedures like factorial or Fibonacci.

338
00:34:42,150 --> 00:34:43,670
It's not true.

339
00:34:43,670 --> 00:34:48,010
So you notice we did recursion here, and all we evaluated was plus X, Y, all right?

340
00:34:48,010 --> 00:34:54,780
The reason that you need recursion in the evaluator is because the evaluation process, itself, is recursive, all right?

341
00:34:54,780 --> 00:34:59,270
It's not because the procedure that you might be evaluating in LISP is a recursive procedure.

342
00:34:59,270 --> 00:35:03,010
So that's an important thing that people get confused about a lot.

343
00:35:03,010 --> 00:35:07,120
The other thing to notice is that, when we're done here, we're really done.

344
00:35:07,120 --> 00:35:13,810
Not only are we at done, but there's no accumulated stuff on the stack, right?

345
00:35:13,810 --> 00:35:17,170
The machine is back to its initial state, all right?

346
00:35:17,170 --> 00:35:19,830
So that's part of what it means to be done.

347
00:35:19,830 --> 00:35:33,460
Another way to say that is the evaluation process has reduced the expression, plus X, Y, to the value here, 7.

348
00:35:33,460 --> 00:35:36,010
And by reduced, I mean a very particular thing.

349
00:35:36,010 --> 00:35:38,180
It means that there's nothing left on the stack.

350
00:35:38,180 --> 00:35:42,760
The machine is now in the same state, except there's something in the value register.

351
00:35:42,760 --> 00:35:44,520
It's not part of a sub-problem of anything.

352
00:35:44,520 --> 00:35:46,210
There's nothing to go back to.

353
00:35:46,210 --> 00:35:46,440
OK.

354
00:35:46,440 --> 00:35:47,690
Let's break.

355
00:35:49,712 --> 00:35:50,159
Question?

356
00:35:50,159 --> 00:35:55,820
AUDIENCE: The question here, in the stack, is because the data may be recursive.

357
00:35:55,820 --> 00:35:59,312
You may have embedded expressions, for instance.

358
00:35:59,312 --> 00:36:02,080
PROFESSOR: Yes, because you might have embedded expressions.

359
00:36:02,080 --> 00:36:12,930
But, again, don't confuse that with what people sometimes mean by the data may be recursive, which is to say you have these list-structured, recursive data list operations.

360
00:36:12,930 --> 00:36:13,980
That has nothing to do with it.

361
00:36:13,980 --> 00:36:17,363
It's simply that the expressions contain sub-expressions.

362
00:36:17,363 --> 00:36:19,618
Yeah?

363
00:36:19,618 --> 00:36:23,225
AUDIENCE: Why is it that the order of the arguments in the arg list got reversed?

364
00:36:23,225 --> 00:36:27,260
PROFESSOR: Ah! Yes, I should've mentioned that.

365
00:36:27,260 --> 00:36:36,050
Here, the reason the order is reversed--  it's a question of what you mean by reversed.

366
00:36:36,050 --> 00:36:40,624
I believe it was Newton.

367
00:36:40,624 --> 00:36:46,840
In the very early part of optics, people realized that, when you look through the lens of your eye, the image was up-side down.

368
00:36:46,840 --> 00:36:51,280
And there was a lot of argument about why that didn't mean you saw things up-side down.

369
00:36:51,280 --> 00:36:52,860
So it's sort of the same issue.

370
00:36:52,860 --> 00:36:54,810
Reversed from what?

371
00:36:54,810 --> 00:36:57,940
So we just need some convention.

372
00:36:57,940 --> 00:37:04,520
The reason that they're coming at 4, 3 is because we're taking UNEV and consing the result onto argl.

373
00:37:04,520 --> 00:37:06,900
So you have to realize you've made that convention.

374
00:37:06,900 --> 00:37:11,230
The place that you have to realize that-- well, there's actually two places.

375
00:37:11,230 --> 00:37:19,490
One is in apply-primitive-operator, which has to realize that the arguments to primitives go in, in the opposite order from the way you're writing them down.

376
00:37:19,490 --> 00:37:28,870
And the other one is, we'll see later when you actually go to bind a function's parameters, you should realize the arguments are going to come in from the opposite order of the variables to which you're binding them.

377
00:37:28,870 --> 00:37:31,830
So, if you just keep track of that, there's no problem.

378
00:37:31,830 --> 00:37:40,730
Also, this is completely arbitrary because, if we'd done, say, an iteration through a vector assigning them, they might come out in the other order, OK?

379
00:37:40,730 --> 00:37:45,085
So it's just a convention of the way this particular evaluator works.

380
00:37:45,085 --> 00:37:46,335
All right, let's take a break.

381
00:38:41,840 --> 00:38:46,950
We just saw evaluating an expression and, of course, that was very simple one.

382
00:38:46,950 --> 00:38:55,130
But, in essence, it would be no different if it was some big nested expression, so there would just be deeper recursion on the stack.

383
00:38:55,130 --> 00:38:56,920
But what I want to do now is show you the last piece.

384
00:38:56,920 --> 00:39:01,300
I want to walk you around this eval and apply loop, right?

385
00:39:01,300 --> 00:39:03,000
That's the thing we haven't seen, really.

386
00:39:03,000 --> 00:39:15,810
We haven't seen any compound procedures where applying a procedure reduces to evaluating the body of the procedure, so let's just suppose we had this.

387
00:39:15,810 --> 00:39:47,280
Suppose we were looking at the procedure define F of A and B to be the sum of A and B. So, as we typed in that procedure previously, and now we're going to evaluate F of X and Y, again, in this environment, E,0, where X is bound to 3 and Y is bound to 4.

388
00:39:50,830 --> 00:39:55,950
When the defined is executed, remember, there's a lambda here, and lambdas create procedures.

389
00:39:55,950 --> 00:40:18,180
And, basically, what will happen is, in E,0, we'll end up with a binding for F, which will say F is a procedure, and its args are A and B, and its body is plus a,b.

390
00:40:18,180 --> 00:40:24,400
So that's what the environment would have looked like had we made that definition.

391
00:40:24,400 --> 00:40:31,810
Then, when we go to evaluate F of X and Y, we'll go through exactly the same process that we did before.

392
00:40:31,810 --> 00:40:33,360
It's even the same expression.

393
00:40:33,360 --> 00:40:41,040
The only difference is that F, instead of having primitive plus in it, will have this thing.

394
00:40:41,040 --> 00:41:08,040
And so we'll go through exactly the same process, except this time, when we end up at apply-dispatch, the function register, instead of having primitive plus, will have a thing that will represent it saying procedure, where the args are A and B, and the body is plus A, B.

395
00:41:08,040 --> 00:41:13,280
And, again, what I mean, by its ENV, I mean there's a pointer to it, so don't worry that I'm writing a lot of stuff there.

396
00:41:13,280 --> 00:41:17,170
There's a pointer to this procedure data structure.

397
00:41:17,170 --> 00:41:20,960
OK, so, we're in exactly the same situation.

398
00:41:20,960 --> 00:41:26,480
We get to apply-dispatch, so, here, we come to apply-dispatch.

399
00:41:26,480 --> 00:41:30,010
Last time, we branched off to a primitive procedure.

400
00:41:30,010 --> 00:41:36,150
Here, it says oh, we now have a compound procedure, so we're going to go off to compound-apply.

401
00:41:38,660 --> 00:41:39,910
Now, what's compound-apply?

402
00:41:42,100 --> 00:41:45,090
Well, remember what the meta-circular evaluator did?

403
00:41:45,090 --> 00:41:54,120
Compound-apply said we're going to evaluate the body of the procedure in some new environment.

404
00:41:54,120 --> 00:41:56,730
Where does that new environment come from?

405
00:41:56,730 --> 00:42:14,990
We take the environment that was packaged with the procedure, we bind the parameters of the procedure to the arguments that we're passing in, and use that as a new frame to extend the procedure environment.

406
00:42:14,990 --> 00:42:21,630
And that's the environment in which we evaluate the procedure body, right?

407
00:42:21,630 --> 00:42:24,470
That's going around the apply/eval loop.

408
00:42:24,470 --> 00:42:27,988
That's apply coming back to call eval, all right?

409
00:42:30,910 --> 00:42:32,860
OK.

410
00:42:32,860 --> 00:42:36,950
So, now, that's all we have to do in compound-apply.

411
00:42:36,950 --> 00:42:37,720
What are we going to do?

412
00:42:37,720 --> 00:42:40,730
We're going to manufacture a new environment.

413
00:42:43,720 --> 00:42:48,310
And we're going to manufacture a new environment, let's see, that we'll call E,1.

414
00:42:53,100 --> 00:43:09,270
E,1 is going to be some environment where the parameters of the procedure, where A is bound to 3 and B is bound to 4, and it's linked to E,0 because that's where f is defined.

415
00:43:09,270 --> 00:43:12,050
And, in this environment, we're going to evaluate the body of the procedure.

416
00:43:12,050 --> 00:43:13,870
So let's look at that, all right?

417
00:43:16,730 --> 00:43:28,300
All right, here we are at compound-apply, which says assign to the expression register the body of the procedure that's in the function register.

418
00:43:28,300 --> 00:43:42,710
So I assign to the expression register the procedure body, OK?

419
00:43:42,710 --> 00:43:57,800
That's going to be evaluated in an environment which is formed by making some bindings using information determined by the procedure-- that's what's in FUN-- and the argument list.

420
00:43:57,800 --> 00:44:01,930
And let's not worry about exactly what that does, but you can see the information's there.

421
00:44:01,930 --> 00:44:08,200
So make bindings will say oh, the procedure, itself, had an environment attached to it.

422
00:44:08,200 --> 00:44:09,320
I didn't write that quite here.

423
00:44:09,320 --> 00:44:13,660
I should've said in environment because every procedure gets built with an environment.

424
00:44:13,660 --> 00:44:19,290
So, from that environment, it knows what the procedure's definition environment is.

425
00:44:19,290 --> 00:44:21,830
It knows what the arguments are.

426
00:44:21,830 --> 00:44:24,280
It looks at argl, and then you see a reversal convention here.

427
00:44:24,280 --> 00:44:29,990
It just has to know that argl is reversed, and it builds this frame, E,1.

428
00:44:29,990 --> 00:44:35,780
All right, so, let's assume that that's what make bindings returns, so it assigns to ENV this thing, E,1.

429
00:44:41,490 --> 00:44:46,890
All right, the next thing it says is restore continue.

430
00:44:46,890 --> 00:44:48,760
Remember what continue was here?

431
00:44:48,760 --> 00:44:52,240
It got put up in the last segment.

432
00:44:52,240 --> 00:44:54,020
Continue got stored.

433
00:44:54,020 --> 00:44:59,920
That was the original done, which said what are you going to do after you're done with this particular application?

434
00:44:59,920 --> 00:45:03,920
It was one of the very first things that happened when we evaluated the application.

435
00:45:03,920 --> 00:45:06,860
And now, finally, we're going to restore continue.

436
00:45:06,860 --> 00:45:09,290
Remember apply-dispatch's contract.

437
00:45:09,290 --> 00:45:13,590
It assumes that where it should go to next was on the stack, and there it was on the stack.

438
00:45:13,590 --> 00:45:19,940
Continue has done, and now we're going to go back to eval-dispatch.

439
00:45:19,940 --> 00:45:20,970
We're set up again.

440
00:45:20,970 --> 00:45:25,511
We have an expression, an environment, and a place to go to.

441
00:45:25,511 --> 00:45:29,940
We're not going to go through that because it's sort of the same expression.

442
00:45:35,167 --> 00:45:44,830
OK, but the thing, again, to notice is, at this point, we have reduced the original expression, F,X,Y, right?

443
00:45:44,830 --> 00:45:52,670
We've reduced evaluating F,X,Y in environment E,0 to evaluate plus A, B in E,1.

444
00:45:52,670 --> 00:45:55,720
And notice, nothing's on the stack, right?

445
00:45:55,720 --> 00:45:56,830
It's a reduction.

446
00:45:56,830 --> 00:46:08,090
At this point, the machine does not contain, as part of its state, the fact that it's in the middle of evaluating some procedure called f, that's gone, right?

447
00:46:08,090 --> 00:46:13,072
There's no accumulated state, OK?

448
00:46:13,072 --> 00:46:14,370
Again, that's a very important idea.

449
00:46:14,370 --> 00:46:21,350
That's the meaning of, when we used to write in the substitution model, this expression reduces to that expression.

450
00:46:21,350 --> 00:46:22,660
And you don't have to remember anything.

451
00:46:22,660 --> 00:46:24,500
And here, you see the meaning of reduction.

452
00:46:24,500 --> 00:46:26,160
At this point, there is nothing on the stack.

453
00:46:31,590 --> 00:46:35,240
See, that has very important consequences.

454
00:46:35,240 --> 00:46:40,590
Let's go back and look at iterative factorial, all right?

455
00:46:40,590 --> 00:46:45,130
Remember, this was some sort of loop and doing iter.

456
00:46:45,130 --> 00:46:49,430
And we kept saying that's an iterative procedure, right?

457
00:46:52,570 --> 00:47:12,360
And what we wrote, remember, are things like, we said, fact-iter of 5.

458
00:47:12,360 --> 00:47:27,210
We wrote things like reduces to iter of 1, and 1, and 5, which reduces to iter of 1, and 2, and 5, and so on, and so on, and so on.

459
00:47:27,210 --> 00:47:31,720
And we kept saying well, look, you don't have to build up any storage to do that.

460
00:47:31,720 --> 00:47:35,040
And we waved our hands, and said in principle, there's no storage needed.

461
00:47:35,040 --> 00:47:36,170
Now, you see no storage needed.

462
00:47:36,170 --> 00:47:39,090
Each of these is a real reduction, right?

463
00:47:49,280 --> 00:48:01,650
As you walk through these expressions, what you'll see are these expressions on the stack in some particular environment, and then these expressions in the EXP register in some particular environment.

464
00:48:01,650 --> 00:48:09,135
And, at each point, there'll be no accumulated stuff on the stack because each one's a real reduction, OK?

465
00:48:09,135 --> 00:48:48,120
All right, so, for example, just to go through it in a little bit more care, if I start out with an expression that says something like, oh, say, fact-iter of 5 in some environment that will, at some point, create an environment in which n is down to 5.

466
00:48:51,340 --> 00:49:17,160
Let's call that--  And, at some point, the machine will reduce this whole thing to a thing that says that's really iter of 1, and 1, and n, evaluated in this environment, E,1 with nothing on the stack.

467
00:49:17,160 --> 00:49:29,366
See, at this moment, the machine is not remembering that evaluating this expression, iter--  which is the loop-- is part of this thing called iterative factorial.

468
00:49:29,366 --> 00:49:30,590
It's not remembering that.

469
00:49:30,590 --> 00:49:33,170
It's just reducing the expression to that, right?

470
00:49:33,170 --> 00:49:42,810
If we look again at the body of iterative factorial, this expression has reduced to that expression.

471
00:49:42,810 --> 00:49:44,060
Oh, I shouldn't have the n there.

472
00:49:46,590 --> 00:49:53,340
It's a slightly different convention from the slide to the program, OK?

473
00:49:53,340 --> 00:49:56,310
And, then, what's the body of iter?

474
00:49:56,310 --> 00:50:00,060
Well, iter's going to be an it, and I won't go through the details of if.

475
00:50:00,060 --> 00:50:02,540
It'll evaluate the predicate.

476
00:50:02,540 --> 00:50:03,810
In this case, it'll be false.

477
00:50:03,810 --> 00:50:43,200
And this iter will now reduce to the expression iter of whatever it says, star, counter product, and-- what does it say-- plus counter 1 in some other environment, by this time, E,2, where E,2 will be set up having bindings for product and counter, right?

478
00:50:43,200 --> 00:50:45,140
And it'll reduce to that, right?

479
00:50:45,140 --> 00:50:49,340
It won't be remembering that it's part of something that it has to return to.

480
00:50:49,340 --> 00:50:59,160
And when iter calls iter again, it'll reduce to another thing that looks like this in some environment, E,3, which has new bindings for product and counter.

481
00:50:59,160 --> 00:51:21,230
So, if you're wondering, see, if you've always been queasy about how it is we've been saying those procedures, that look syntactically recursive, are, in fact, iterative, run in constant space, well, I don't know if this makes you less queasy, but at least it shows you what's happening.

482
00:51:21,230 --> 00:51:22,830
There really isn't any buildup there.

483
00:51:25,910 --> 00:51:31,710
Now, you might ask well, is there buildup in principle in these environment frames?

484
00:51:31,710 --> 00:51:36,440
And the answer is yeah, you have to make these new environment frames, but you don't have to hang onto them when you're done.

485
00:51:36,440 --> 00:51:40,720
They can be garbage collected, or the space can be reused automatically.

486
00:51:40,720 --> 00:51:50,132
But you see the control structure of the evaluator is really using this idea that you actually have a reduction, so these procedures really are iterative procedures.

487
00:51:50,132 --> 00:51:51,382
All right, let's stop for questions.

488
00:52:02,288 --> 00:52:03,538
All right, let's break.

489
00:52:48,770 --> 00:52:58,030
Let me contrast the iterative procedure just so you'll see where space does build up with a recursive procedure, so you can see the difference.

490
00:52:58,030 --> 00:53:02,880
Let's look at the evaluation of recursive factorial, all right?

491
00:53:02,880 --> 00:53:07,220
So, here's fact-recursive, or standard factorial definition.

492
00:53:07,220 --> 00:53:13,750
We said this one is still a recursive procedure, but this is actually a recursive process.

493
00:53:13,750 --> 00:54:15,240
And then, just to link it back to the way we started, we said oh, you can see that it's going to be recursive process by the substitution model because, if I say recursive factorial of 5, that turns into 5 times-- what is it, fact-rec, or record fact--  5 times recursive factorial of 4, which turns into 5 times 4 times fact-rec of 3, which returns into 5 times 4 times 3 times, and so on, right?

494
00:54:15,240 --> 00:54:21,520
The idea is there was this chain of stuff building up, which justified, in the substitution model, the fact that it's recursive.

495
00:54:21,520 --> 00:54:27,465
And now, let's actually see that chain of stuff build up and where it is in the machine, OK?

496
00:54:27,465 --> 00:54:30,230
All right, well, let's imagine we're going to start out again.

497
00:54:30,230 --> 00:54:49,580
We'll tell it to evaluate recursive factorial of 5 in some environment, again, E,0 where recursive factorial is defined, OK?

498
00:54:49,580 --> 00:54:52,490
Well, now we know what's eventually going to happen.

499
00:54:52,490 --> 00:55:14,610
This is going to come along, it'll evaluate those things, figure out it's a procedure, build somewhere over here an environment, E,1, which has n bound to 5, which hangs off of E,0, which would be, presumably, the definition environment of recursive factorial, OK?

500
00:55:14,610 --> 00:55:19,670
And, in this environment, it's going to go off and evaluate the body.

501
00:55:19,670 --> 00:55:30,240
So, again, the evaluation here will reduce to evaluating the body in E,1.

502
00:55:30,240 --> 00:55:33,530
That's going to look at an if, and I won't go through the details of if.

503
00:55:33,530 --> 00:55:34,880
It'll look at the predicate.

504
00:55:34,880 --> 00:55:37,840
It'll decide it eventually has to evaluate the alternative.

505
00:55:37,840 --> 00:56:08,720
So this whole thing, again, will reduce to the alternative of recursive factorial, the alternative clause, which says that this whole thing reduces to times n of recursive factorial of n minus 1 in the environment E,1, OK?

506
00:56:08,720 --> 00:56:14,130
So the original expression, now, is going to reduce to evaluating that expression, all right?

507
00:56:14,130 --> 00:56:16,280
Now we have an application.

508
00:56:16,280 --> 00:56:18,500
We did an application before.

509
00:56:18,500 --> 00:56:20,390
Remember what happens in an application?

510
00:56:20,390 --> 00:56:25,350
The first thing you do is you go off and you save the value of the continue register on the stack.

511
00:56:25,350 --> 00:56:27,365
So the stack here is going to have done in it.

512
00:56:29,980 --> 00:56:35,130
And then you're going to set up to evaluate the sub-parts, OK?

513
00:56:35,130 --> 00:56:36,710
So here we go off to evaluate the sub-parts.

514
00:56:39,520 --> 00:56:41,045
First thing we're going to do is evaluate the operator.

515
00:56:44,490 --> 00:56:47,250
What happens when we evaluate an operator?

516
00:56:47,250 --> 00:56:51,480
Well, we arrange things so that the operator ends up in the expression register.

517
00:56:51,480 --> 00:56:56,590
The environments in the ENV register continue someplace where we're going to go evaluate the arguments.

518
00:56:56,590 --> 00:57:01,720
And, on the stack, we've saved the original continue, which is where we wanted to be when we're all done.

519
00:57:01,720 --> 00:57:15,620
And then the things we needed when we're going to get done evaluating the operator, the things we'll need to evaluate the arguments, namely, the environment and those arguments, those unevaluated arguments, so there they are sitting on the stack.

520
00:57:15,620 --> 00:57:18,370
And we're about to go off to evaluate the operator.

521
00:57:23,130 --> 00:57:43,080
Well, when we return from this particular call-- so we're about to call eval-dispatch here-- when we return from this call, the value of that operator, which, in this case, is going to be the primitive multiplier procedure, will end up in the FUN register, all right?

522
00:57:43,080 --> 00:57:44,530
We're going to evaluate some arguments.

523
00:57:44,530 --> 00:57:47,730
They will evaluate in here.

524
00:57:47,730 --> 00:57:50,250
That'll give us 5, in this case.

525
00:57:50,250 --> 00:57:57,460
We're going to put that in the argl register, and then we'll go off to evaluate the second operand.

526
00:57:57,460 --> 00:58:09,460
So, at the point where we go off to evaluate the second operand-- and I'll skip details like computing, and minus 1, and all of that-- but, when we go off to evaluate the second operand, that will eventually reduce to another call to fact-recursive.

527
00:58:12,060 --> 00:58:23,790
And, what we've got on the stack here is the operator from that combination that we're going to use it in and the other argument, OK?

528
00:58:23,790 --> 00:58:30,200
So, now, we're set up for another call to recursive factorial.

529
00:58:30,200 --> 00:58:33,935
And, when we're done with this one, we're going to go to accumulate the last arg.

530
00:58:33,935 --> 00:58:35,200
And remember what that'll do?

531
00:58:35,200 --> 00:58:41,690
That'll say oh, whatever the result of this has to get combined with that, and we're going to multiply them.

532
00:58:41,690 --> 00:58:45,720
But, notice now, we're at another recursive factorial.

533
00:58:45,720 --> 00:58:53,700
We're about to call eval-dispatch again, except we haven't really reduced it because there's stuff on the stack now.

534
00:58:53,700 --> 00:58:58,430
The stuff on the stack says oh, when you get back, you'd better multiply it by the 5 you had hanging there.

535
00:58:58,430 --> 00:59:09,300
So, when we go off to make another call, we evaluate the n minus 1.

536
00:59:09,300 --> 00:59:14,600
That gives us another environment in which the new n's going to be down to 4.

537
00:59:14,600 --> 00:59:18,930
And we're about to call eval-dispatch again, right?

538
00:59:18,930 --> 00:59:21,350
We get another call.

539
00:59:21,350 --> 00:59:26,040
That 4 is going to end up in the same situation.

540
00:59:26,040 --> 00:59:30,020
We'll end up with another call to fact-recursive n.

541
00:59:30,020 --> 00:59:35,360
And sitting on the stack will be the stuff from the original one and, now, the subsidiary one we're doing.

542
00:59:35,360 --> 00:59:36,910
And both of them are waiting for the same thing.

543
00:59:36,910 --> 00:59:40,600
They're going to go to accumulate a last argument.

544
00:59:40,600 --> 00:59:45,640
And then, of course, when we go to the fourth call, the same thing happens, right?

545
00:59:45,640 --> 00:59:47,300
And this goes on, and on, and on.

546
00:59:47,300 --> 00:59:54,960
And what you see here on the stack, exactly what's sitting here on the stack, the thing that says times and 5.

547
00:59:54,960 --> 01:00:00,470
And what you're going to do with that is accumulate that into a last argument.

548
01:00:00,470 --> 01:00:02,760
That's exactly this, right?

549
01:00:02,760 --> 01:00:05,650
This is exactly where that stuff is hanging.

550
01:00:05,650 --> 01:00:19,620
Effectively, the operator you're going to apply, the other argument that it's got to be multiplied by when you get back and the parentheses, which says yeah, what you wanted to do was accumulate them.

551
01:00:19,620 --> 01:00:22,560
So, you see, the substitution model is not such a lie.

552
01:00:22,560 --> 01:00:27,198
That really is, in some sense, what's sitting right on the stack.

553
01:00:27,198 --> 01:00:29,046
OK.

554
01:00:29,046 --> 01:00:49,430
All right, so that, in some sense, should explain for you, or at least convince you, that, somehow, this evaluator is managing to take these procedures and execute some of them iteratively and some of them recursively, even though, as syntactically, they look like recursive procedures.

555
01:00:49,430 --> 01:00:50,660
How's it managing to do that?

556
01:00:50,660 --> 01:01:01,090
Well, the basic reason it's managing to do that is the evaluator is set up to save only what it needs later.

557
01:01:01,090 --> 01:01:20,160
So, for example, at the point where you've reduced evaluating an expression and an environment to applying a procedure to some arguments, it doesn't need that original environment anymore because any environment stuff will be packaged inside the procedures where the application's going to happen.

558
01:01:20,160 --> 01:01:31,500
All right, similarly, when you're going along evaluating an argument list, when you've finished evaluating the list, when you're finished evaluating the last argument, you don't need that argument list any more, right?

559
01:01:31,500 --> 01:01:36,690
And you don't need the environment where those arguments would be evaluated, OK?

560
01:01:36,690 --> 01:01:43,050
So the basic reason that this interpreter is being so smart is that it's not being smart at all, it's being stupid.

561
01:01:43,050 --> 01:01:46,010
It's just saying I'm only going to save what I really need.

562
01:01:48,700 --> 01:01:51,000
Well, let me show you here.

563
01:01:54,880 --> 01:01:58,310
Here's the actual thing that's making a tail recursive.

564
01:01:58,310 --> 01:02:00,135
Remember, it's the restore of continue.

565
01:02:00,135 --> 01:02:15,170
It's saying when I go off to evaluate the procedure body, I should tell eval to come back to the place where that original evaluation was supposed to come back to.

566
01:02:15,170 --> 01:02:18,770
So, in some sense, you want to say what's the actual line that makes a tail recursive?

567
01:02:18,770 --> 01:02:19,920
It's that one.

568
01:02:19,920 --> 01:02:39,920
If I wanted to build a non-tail recursive evaluator, for some strange reason, all I would need to do is, instead of restoring continue at this point, I'd set up a label down here called, "Where to come back after you've finished applying the procedure." Instead, I'd set continue to that.

569
01:02:39,920 --> 01:02:43,790
I'd go to eval-dispatch, and then eval-dispatch would come back here.

570
01:02:43,790 --> 01:02:47,920
At that point, I would restore continue and go to the original one.

571
01:02:47,920 --> 01:02:52,840
So here, the only consequence of that would be to make it non-tail recursive.

572
01:02:52,840 --> 01:02:59,500
It would give you exactly the same answers, except, if you did that iterative factorial and all those iterative procedures, it would execute recursively.

573
01:03:03,080 --> 01:03:13,890
Well, I lied to you a little bit, but just a little bit, because I showed you a slightly over-simplified evaluator where it assumes that each procedure body has only one expression.

574
01:03:13,890 --> 01:03:17,870
Remember, in general, a procedure has a sequence of expressions in it.

575
01:03:17,870 --> 01:03:20,490
So there's nothing really conceptually new.

576
01:03:20,490 --> 01:03:24,730
Let me just show you the actual evaluator that handles sequences of expressions.

577
01:03:28,470 --> 01:03:42,670
This is compound-apply now, and the only difference from the old one is that, instead of going off to eval directly, it takes the whole body of the procedure, which, in this case, is a sequence of expressions, and goes off to eval-sequence.

578
01:03:42,670 --> 01:03:49,980
And eval-sequence is a little loop that, basically, does these evaluations one at a time.

579
01:03:52,630 --> 01:03:53,900
So it does an evaluation.

580
01:03:53,900 --> 01:03:58,440
Says oh, when I come back, I'd better come back here to do the next one.

581
01:03:58,440 --> 01:04:06,410
And, when I'm all done, when I want to get the last expression, I just restore my continue and go off to eval-dispatch.

582
01:04:06,410 --> 01:04:14,900
And, again, if you wanted for some reason to break tail recursion in this evaluator, all you need to do is not handle the last expression, especially.

583
01:04:14,900 --> 01:04:21,900
Just say, after you've done the last expression, come back to some other place after which you restore continue.

584
01:04:21,900 --> 01:04:26,550
And, for some reason, a lot of LISP evaluators tended to work that way.

585
01:04:26,550 --> 01:04:31,614
And the only consequence of that is that iterative procedures built up stack.

586
01:04:31,614 --> 01:04:35,670
And it's not clear why that happened.

587
01:04:35,670 --> 01:04:36,210
All right.

588
01:04:36,210 --> 01:04:41,120
Well, let me just sort of summarize, since this is a lot of details in a big program.

589
01:04:41,120 --> 01:04:47,060
But the main point is that it's no different, conceptually, from translating any other program.

590
01:04:47,060 --> 01:04:51,870
And the main idea is that we have this universal evaluator program, the meta-circular evaluator.

591
01:04:51,870 --> 01:04:54,560
If we translate that into LISP, then we have all of LISP.

592
01:04:54,560 --> 01:04:57,980
And that's all we did, OK?

593
01:04:57,980 --> 01:04:59,680
The second point is that the magic's gone away.

594
01:04:59,680 --> 01:05:01,970
There should be no more magic in this whole system, right?

595
01:05:04,820 --> 01:05:12,640
In principle, it should all be very clear except, maybe, for how list structured memory works, and we'll see that later.

596
01:05:12,640 --> 01:05:15,450
But that's not very hard.

597
01:05:15,450 --> 01:05:25,870
The third point is that all this tail recursion came from the discipline of eval being very careful to save only what it needs next time.

598
01:05:25,870 --> 01:05:33,940
It's not some arbitrary thing where we're saying well, whenever we call a sub-routine, we'll save all the registers in the world and come back, right?

599
01:05:33,940 --> 01:05:37,150
See, sometimes it pays to really worry about efficiency.

600
01:05:37,150 --> 01:05:45,230
And, when you're down in the guts of your evaluator machine, it really pays to think about things like that because it makes big consequences.

601
01:05:45,230 --> 01:05:52,560
Well, I hope what this has done is really made the evaluator seem concrete, right?

602
01:05:52,560 --> 01:05:59,390
I hope you really believe that somebody could hold a LISP evaluator in the palm of their hand.

603
01:05:59,390 --> 01:06:06,160
Maybe to help you believe that, here's a LISP evaluator that I'm holding the palm of my hand, right?

604
01:06:06,160 --> 01:06:13,700
And this is a chip which is actually quite a bit more complicated than the evaluator I showed you.

605
01:06:17,815 --> 01:06:19,200
Maybe, here's a better picture of it.

606
01:06:22,070 --> 01:06:24,730
What there is, is you can see the same overall structure.

607
01:06:24,730 --> 01:06:26,940
This is a register array.

608
01:06:26,940 --> 01:06:27,910
These are the data paths.

609
01:06:27,910 --> 01:06:29,800
Here's a finite state controller.

610
01:06:29,800 --> 01:06:32,810
And again, finite state, that's all there is.

611
01:06:32,810 --> 01:06:35,750
And somewhere there's external memory that'll worry about things.

612
01:06:35,750 --> 01:06:57,120
And this particular one is very complicated because it's trying to run LISP fast. And it has some very, very fast parallel operations in there like, if you want to index into an array, simultaneously check that the index is an integer, check that it doesn't exceed the array bands, and go off and do the memory access, and do all those things simultaneously.

613
01:06:57,120 --> 01:07:00,420
And then, later, if they're all OK, actually get the value there.

614
01:07:00,420 --> 01:07:06,550
So there are a lot of complicated operations in these data paths for making LISP run in parallel.

615
01:07:06,550 --> 01:07:10,640
It's a completely non-risk philosophy of evaluating LISP.

616
01:07:10,640 --> 01:07:13,740
And then, this microcode is pretty complicated.

617
01:07:13,740 --> 01:07:17,740
Let's see, there's what?

618
01:07:17,740 --> 01:07:27,940
There's about 389 instructions of 220-bit microcode sitting here because these are very complicated data paths.

619
01:07:27,940 --> 01:07:33,580
And the whole thing has about 89,000 transistors, OK?

620
01:07:33,580 --> 01:07:33,840
OK.

621
01:07:33,840 --> 01:07:37,970
Well, I hope that that takes away a lot of the mystery.

622
01:07:37,970 --> 01:07:39,240
Maybe somebody wants to look at this.

623
01:07:42,048 --> 01:07:43,298
Yeah.

624
01:07:46,260 --> 01:07:46,480
OK.

625
01:07:46,480 --> 01:07:47,730
Let's stop.

626
01:07:55,890 --> 01:07:57,815
Questions?

627
01:07:57,815 --> 01:08:15,165
AUDIENCE: OK, now, it sounds like what you're saying is that, with the restore continue put in the proper place, that procedures that would invoke a recursive process now invoke an integer process just by the way that the eval signature is?

628
01:08:15,165 --> 01:08:28,029
PROFESSOR: I think the way I'd prefer to put it is that, with restore continue put in the wrong place, you can cause any syntactically-looking recursive procedure, in fact, to build up stack as it runs.

629
01:08:28,029 --> 01:08:35,660
But there's no reason for that, so you might want to play around with it.

630
01:08:35,660 --> 01:08:45,060
You can just switch around two or three instructions in the way compound-apply comes back, and you'll get something which isn't tail recursive.

631
01:08:45,060 --> 01:08:47,670
But the thing I wanted to emphasize is there's no magic.

632
01:08:47,670 --> 01:09:01,060
It's not as if there's some very clever pre-processing program that's looking at this procedure, factorial iter, and say oh, gee, I really notice that I don't have to push stack in order to do this.

633
01:09:01,060 --> 01:09:03,760
Some people think that that's what's going on.

634
01:09:03,760 --> 01:09:08,880
It's something much, much more dumb than that, it's this one place you're putting the restore instruction.

635
01:09:08,880 --> 01:09:10,353
It's just automatic.

636
01:09:10,353 --> 01:09:11,603
AUDIENCE: OK.

637
01:09:14,217 --> 01:09:17,850
AUDIENCE: But that's not affecting the time complexity is it?

638
01:09:17,850 --> 01:09:18,275
PROFESSOR: No.

639
01:09:18,275 --> 01:09:23,020
AUDIENCE: It's just that it's handling it recursively instead of iteratively.

640
01:09:23,020 --> 01:09:29,220
But, in terms of the order of time it takes to finish the operation, it's the same one way or the other, right?

641
01:09:29,220 --> 01:09:29,920
PROFESSOR: Yes.

642
01:09:29,920 --> 01:09:36,029
Tail recursion is not going to change the time complexity of anything because, in some sense, it's the same algorithm that's going on.

643
01:09:36,029 --> 01:09:41,210
What it's doing is really making this thing run as an iteration, right?

644
01:09:41,210 --> 01:09:47,683
Not going to run out of memory counting up to a giant number simply because the stack would get pushed.

645
01:09:47,683 --> 01:09:57,990
See, the thing you really have to believe is that, when we write-- see, we've been writing all these things called iterations, infinite loops, define loop to be called loop.

646
01:10:01,660 --> 01:10:07,630
That's is as much an iteration as if we wrote do forever loop, right?

647
01:10:07,630 --> 01:10:09,280
It's just syntactic sugar as the difference.

648
01:10:09,280 --> 01:10:14,730
These things are real, honest to god, iterations, right?

649
01:10:14,730 --> 01:10:18,535
They don't change the time complexity, but they turn them into real iterations.

650
01:10:21,686 --> 01:10:23,800
All right, thank you.