1 00:00:03,600 --> 00:00:07,843 In this video we're going to continue and complete our discussion of cool 2 00:00:07,843 --> 00:00:12,544 operational semantics. We'll be taking a look with the two most complex operations 3 00:00:12,544 --> 00:00:19,477 in cool, the allocation of the new object and dynamic dispatch. We'll begin by 4 00:00:19,477 --> 00:00:24,479 giving an informal discussion of what happens when a new object is allocated in 5 00:00:24,479 --> 00:00:29,231 Kuhl. So, the first thing that has to happen, if we have to allocate space for 6 00:00:29,231 --> 00:00:33,796 the object and essentially, that means having enough space for the object 7 00:00:33,796 --> 00:00:38,423 attributes. We're going to have to allocate a location for every attribute of 8 00:00:38,423 --> 00:00:43,738 the object of class t if what we're doing is allocating a new t object. Then we're 9 00:00:43,738 --> 00:00:48,868 going to set the attributes of, of that object to their default values and well in 10 00:00:48,868 --> 00:00:54,061 a few minutes, we'll see what the default values are and why we need to set the, set 11 00:00:54,061 --> 00:00:58,691 the attributes to defaults. And then we evaluate the initializers so every 12 00:00:58,691 --> 00:01:03,508 attribute in the class declaration can have an initializing expression. We're 13 00:01:03,508 --> 00:01:08,216 going to evaluate those and set the resulting attribute values And then we 14 00:01:08,216 --> 00:01:13,262 return the newly allocated objects. So these are the steps that are involved in 15 00:01:13,262 --> 00:01:18,692 setting a new object and as you can see it's actually more than just allocating a 16 00:01:18,692 --> 00:01:23,419 little bit of memory. It's actually quite a bit of computation going on in 17 00:01:23,419 --> 00:01:29,700 allocating new objects in cool. Every class has a default value associated with 18 00:01:29,700 --> 00:01:35,444 that class. So for integers, the default value is zero. For Boolean, the default 19 00:01:35,444 --> 00:01:41,636 value is a Boolean false and for strings, the default value is the empty string And 20 00:01:41,636 --> 00:01:47,752 then for any other class, that isn't one of these three basic classes or any other 21 00:01:47,752 --> 00:01:54,422 class, the default value is void. In the operational rules, we're going to need a 22 00:01:54,422 --> 00:01:59,602 way to repair to the attributes of a class. So we're going to define a function 23 00:01:59,602 --> 00:02:05,242 called class that takes a class name and returns the list of attributes of, of that 24 00:02:05,242 --> 00:02:10,553 class. So here we have all the attributes of class a, let's say that a1 through and 25 00:02:10,815 --> 00:02:15,996 in addition, this functions also going to tell us for each attribute declared type 26 00:02:15,996 --> 00:02:21,456 of the attribute and the expression that initiali zes the attribute. And one other 27 00:02:21,456 --> 00:02:27,856 important feature of this list, is that it includes all the attributes of class a 28 00:02:27,856 --> 00:02:34,104 including the inherited ones. And there's another detail which is in what order 29 00:02:34,104 --> 00:02:40,351 these attributes appear and these are actually become important when we define 30 00:02:40,580 --> 00:02:46,599 the semantics of how attributes are initialized and the rule is the attributes 31 00:02:46,599 --> 00:02:56,693 are listed in greatest ancestor first order And what do I mean by that? Let's 32 00:02:56,693 --> 00:03:08,524 say that we have three classes a, b, and c and a, I'm sorry, b inherits from a. And c 33 00:03:08,524 --> 00:03:20,340 inherits. From b. Okay, let's say, that a defines two attributes, a1 and a2 and b 34 00:03:20,340 --> 00:03:29,882 defines two attributes b1, b2 and c defines two attributes c1 and c2. Then 35 00:03:29,882 --> 00:03:39,309 class of c. We'll list the attributes in the following order. First we'll come a1 36 00:03:39,309 --> 00:03:45,710 and then a2 Because a is the greatest ancestor, okay, it's the, the closest to 37 00:03:45,710 --> 00:03:50,999 the root of the object hierarchy and the attribute was in class a or within any 38 00:03:50,999 --> 00:03:56,157 class, it's always listed in the order that it textually appear. So, first comes 39 00:03:56,157 --> 00:04:01,711 a1 and a2 and of course the type in the initializer are also, let's see here, most 40 00:04:01,711 --> 00:04:06,736 of these attributes but we're just concentrating here in the order in which 41 00:04:06,934 --> 00:04:12,112 the information appears. So, the next would come class b. So, the attributes of 42 00:04:12,112 --> 00:04:16,906 class b will be next and of course, there'll be the type and initialize for 43 00:04:16,906 --> 00:04:21,956 those attributes and then finally the attributes of class c Again, in the order 44 00:04:21,956 --> 00:04:26,686 in which they are listed in the class definition, okay? So, that defines the 45 00:04:26,686 --> 00:04:31,928 order of the attributes for any class. It's always in the order of the greatest 46 00:04:31,928 --> 00:04:37,937 ancestor down the inheritance chain to the class itself which is the argument of the 47 00:04:37,937 --> 00:04:46,038 class functions. At this point we're ready to actually define the formal semantics of 48 00:04:46,038 --> 00:04:53,072 new t and let switch colors here. So we're going to be allocating a new object of 49 00:04:53,072 --> 00:04:59,520 type and is going to be in a context with self object as zero environment e and 50 00:04:59,520 --> 00:05:04,348 store s. The first thing we have to do we're going to figure out what kind of 51 00:05:04,348 --> 00:05:09,410 object it is that we're actually going to allocate and the only question is whether 52 00:05:09,410 --> 00:05:14,111 t is se lf type or not because remember self type is not the name of an actual 53 00:05:14,111 --> 00:05:18,631 class. If t is not self type then the class that we're going to allocate is 54 00:05:18,631 --> 00:05:23,453 actually a t. T is actually a class name and with that, that's the kind of object 55 00:05:23,453 --> 00:05:28,455 that we're going to allocate. If t is self type then the kind of object we're going 56 00:05:28,455 --> 00:05:33,374 to be allocating. Is whatever the class is of the self objects? So we're going to 57 00:05:33,374 --> 00:05:38,827 look at the dynamic type here of the self object called that x and that will be the 58 00:05:38,827 --> 00:05:43,826 class that we create. That will be the kind of objects that we created, all 59 00:05:43,826 --> 00:05:48,370 right? So there's two possibilities, Either object, object, allocating an 60 00:05:48,370 --> 00:05:54,212 object of type t if t is actually a class name. Otherwise it's an object of the same 61 00:05:54,212 --> 00:06:00,466 dynamic type as the self object Alright? So, now we're going to look up t0 is, 62 00:06:00,466 --> 00:06:08,287 alright. And we get out the list of the attribute types and initializers for t0. 63 00:06:08,287 --> 00:06:15,659 So, this tells that what we have to do to construct an object of this type. Alright 64 00:06:15,659 --> 00:06:20,958 and the next thing we do is we allocate locations for each of the attributes. So, 65 00:06:20,958 --> 00:06:25,793 because they were in attributes, we're going to allocate n locations. One for 66 00:06:25,793 --> 00:06:31,157 each attribute, all right. And then we're going to create an object with the class 67 00:06:31,157 --> 00:06:36,456 tag t0 and the attributes are going to be bound to these new locations. So, the i 68 00:06:36,456 --> 00:06:41,886 attribute will be abound to the i new location that we just allocated and that 69 00:06:41,886 --> 00:06:47,071 were going to update the store. Okay. So, we're going to take our initial store and 70 00:06:47,071 --> 00:06:52,401 know this is the same with the store we started with. We take s and we are going 71 00:06:52,401 --> 00:06:57,264 to update it so that at these new locations, those new locations hold the 72 00:06:57,264 --> 00:07:02,794 default values of, for the type of each of the attribute. Okay, and that gives us the 73 00:07:02,794 --> 00:07:08,390 store s1 and now we have to evaluate the initializer. The two actually, initialize 74 00:07:08,390 --> 00:07:13,736 the attributes. And we have to think about what the environment is in which those 75 00:07:13,736 --> 00:07:19,069 attributes are initialized and remember the rule is that within initializer I 76 00:07:19,069 --> 00:07:24,008 mean, attribute, all the attributes of the class are in scope. Alright, so the 77 00:07:24,008 --> 00:07:28,881 environment in this case for the initializers will ju st consist of the 78 00:07:28,881 --> 00:07:33,773 initializer or the attributes, excuse me, themselves. Okay, so these are the 79 00:07:33,773 --> 00:07:39,140 attribute names and the i attributes is bound to the i's new memory location 80 00:07:39,140 --> 00:07:44,557 holding the value, the default value initially of that attribute. Alright, and 81 00:07:44,557 --> 00:07:49,792 then finally, to evaluate initializers, we just evaluate them as a block in the order 82 00:07:49,792 --> 00:07:54,778 which they appear in the class function. This is why it was important to specify 83 00:07:54,778 --> 00:07:59,874 the order in the class function. So remember that these attributes include all 84 00:07:59,874 --> 00:08:04,750 the inherited attribute so we'll start by evaluating initializing attributes with 85 00:08:04,750 --> 00:08:09,984 the greatest ancestor and working our way down to the attributes declared within the 86 00:08:09,984 --> 00:08:15,242 class itself. Notice that the environment here. Which has all of the attributes in 87 00:08:15,242 --> 00:08:20,155 scope is an interesting point, this environment has nothing to do with the 88 00:08:20,155 --> 00:08:25,465 environment in which new t is actually evaluation. You know, these environments e 89 00:08:25,465 --> 00:08:30,909 and e prime are completely separate, okay? So new, so e prime has in scope the names 90 00:08:30,909 --> 00:08:35,954 of the attributes the class e is a, you know, is, is some other environment. 91 00:08:35,954 --> 00:08:41,199 There's some functions somewhere that's calling new t and the variables are in 92 00:08:41,199 --> 00:08:46,773 scope there are just completely different, okay? But anyway, evaluating this block Of 93 00:08:46,773 --> 00:08:52,999 initializers will yield some value. And the new store the value isn't used for 94 00:08:52,999 --> 00:08:58,682 anything, okay? But the new store is the final store. That's the store that we get 95 00:08:58,682 --> 00:09:04,365 out as a result of allocating the object and then what is the result of new t, well 96 00:09:04,365 --> 00:09:09,458 it is the new object itself, v. To summarize the semantics of New that was 97 00:09:09,458 --> 00:09:14,280 the first three steps allocate the object [inaudible] actually allocate the memory 98 00:09:14,280 --> 00:09:18,820 for the object and then the remaining steps initialize the objects by evaluating 99 00:09:18,820 --> 00:09:23,193 a sequence of assignments and the most important thing probably to understand 100 00:09:23,193 --> 00:09:27,790 about initialization and one of the most important things is the context in which 101 00:09:27,958 --> 00:09:32,652 or the stage in which the initializers are evaluated. So know that only the attribute 102 00:09:32,652 --> 00:09:37,013 are in scope while we emphasize that and it's the same rule as of typing. So when 103 00:09:37,013 --> 00:09:41,374 you 're type checking a class declaration only the attributes are in scope of the 104 00:09:41,374 --> 00:09:45,574 you know, for the initializers of the class and then as the same, naturally the 105 00:09:45,574 --> 00:09:50,204 same thing that we use when we actually evaluate the initializers at runtime. And 106 00:09:50,204 --> 00:09:55,884 the initial values of the attributes are the default values and then, then we need 107 00:09:55,884 --> 00:10:01,494 the defaults because, precisely because the attributes are in-sculpt inside their 108 00:10:01,494 --> 00:10:06,896 own initializers. So, it could be for example, it's perfectly reasonable like 109 00:10:06,896 --> 00:10:12,111 Kuhls to have an initializer, let's say, like this. And I'm just going to, I may 110 00:10:12,111 --> 00:10:17,707 leave all the types here just to save time but I can assign and attribute a the value 111 00:10:17,707 --> 00:10:23,043 of a and this is perfectly okay because the right hand side of the intializer has 112 00:10:23,043 --> 00:10:28,443 all the attributes and scope and for this to make sense a has to have some kind of 113 00:10:28,443 --> 00:10:33,909 default value. It has to have some initial value so because I might read it, before I 114 00:10:33,909 --> 00:10:38,529 might read an attribute before I have actually finished computing its 115 00:10:38,529 --> 00:10:43,620 initializer All right? And the last point here, is that notice that in the 116 00:10:43,620 --> 00:10:49,211 initialization or in the yeah, in the initialization of an object self is the 117 00:10:49,211 --> 00:10:54,600 object itself is the self object. And what do I mean by that? I forgot to mention 118 00:10:54,600 --> 00:11:00,393 this on the previous slide just flipping back to that slide for a moment, notice 119 00:11:00,393 --> 00:11:06,142 here. That in the evaluation of the initializers, what is the context the self 120 00:11:06,142 --> 00:11:11,482 object is v, the self object is v, this is the new object that we have just 121 00:11:11,482 --> 00:11:16,606 constructed. And so, it's perfectly fine for e1 or en, the initialization 122 00:11:16,606 --> 00:11:22,163 expressions over here and refers to stealth and what they were referred to if 123 00:11:22,163 --> 00:11:29,540 they use self is the object that is being initialized. Alright Returning to this, to 124 00:11:29,540 --> 00:11:36,640 our summary you know it might be a little bit of a surprise how complicated the. 125 00:11:36,640 --> 00:11:42,823 Semantics of new is, in cool and it's not just cool that has that property. In fact 126 00:11:42,823 --> 00:11:48,781 every object oriented language, language has a fairly complex semantics for the 127 00:11:48,781 --> 00:11:54,965 initialization of new objects and it's a combination of features like inheritance 128 00:11:54,965 --> 00:12:01,224 and the ability of initializers to refer to the attributes that leads to this kind 129 00:12:01,224 --> 00:12:08,251 of complexity. Now let's talk about the semantics of dynamic dispatch and we'll 130 00:12:08,251 --> 00:12:13,237 follow the same plan that we did the semantics of new for us giving for us have 131 00:12:13,237 --> 00:12:17,911 an informal discussion and high level description of how the evaluation of 132 00:12:17,911 --> 00:12:22,960 dynamic dispatch works and then we'll look at the formal operational rule. So the 133 00:12:22,960 --> 00:12:27,634 first thing it happens in evaluating a dispatch is that we'll evaluate the 134 00:12:27,634 --> 00:12:32,433 arguments e1 through en and next we'll evaluate the target object e0 so that 135 00:12:32,433 --> 00:12:37,606 expression to get the actual object to which we're dispatching. Next, we're going 136 00:12:37,606 --> 00:12:43,400 to look at the dynamic type of the target object. So, after we evaluate the zero, 137 00:12:43,400 --> 00:12:49,413 we're going to look at its class peg is And then, we're going to use that type to 138 00:12:49,413 --> 00:12:55,500 figure out which function which function f we're supposed to use. So, we're going to 139 00:12:55,500 --> 00:13:01,660 go and look in the method table for the class x and see what method it has for f. 140 00:13:02,500 --> 00:13:08,735 There we're going to create new locations and environment [inaudible]. Alright, and 141 00:13:08,735 --> 00:13:14,285 we're going to set up a new locations for the actual parameters. We're going to 142 00:13:14,285 --> 00:13:21,812 initialize the, those locations with the actual arguments. Where s itself to be the 143 00:13:21,812 --> 00:13:29,841 target object and then we're going to evaluate the body of f. Now in order to do 144 00:13:29,841 --> 00:13:35,323 the look up of a method in a class, we're going to need some representation of what 145 00:13:35,323 --> 00:13:40,668 methods exist and which class is in our operational rules. So we're going to find 146 00:13:40,668 --> 00:13:46,355 a function eval stands for implementation and the implementation in a class a of a 147 00:13:46,355 --> 00:13:51,905 method f is, is going to be first of all, the list of formal parameters. So it's 148 00:13:51,905 --> 00:13:56,907 going to tell us what the formal parameters are of f and then the body of f 149 00:13:56,907 --> 00:14:04,183 Whatever the, the function body of f is. Now we're ready to actually discuss the 150 00:14:04,183 --> 00:14:09,214 details of the formal operational semantics of method dispatch in Kuhl. I'm 151 00:14:09,214 --> 00:14:14,916 going to switch colors here again just for contrast. So as we said, the first thing 152 00:14:14,916 --> 00:14:20,349 we do is we evaluate the n arguments. So this first in lines, take care of that ad 153 00:14:20,349 --> 00:14:25,179 notice that each arguments that's evaluated may have side effects. So, it 154 00:14:25,179 --> 00:14:30,679 starts in some store but it may produce a different store. So after we've done all 155 00:14:30,679 --> 00:14:35,767 of this we'll have the n arguments evaluated and some store s (N). The next 156 00:14:35,767 --> 00:14:42,073 thing that happens is we evaluate zero. This is the expression to which we are 157 00:14:42,073 --> 00:14:48,056 dispatching and that would give us an object v0 and some updated store s (n) + 158 00:14:48,056 --> 00:14:53,976 one. Okay And now we have to inspect v0. We want to know what's inside of v0, what 159 00:14:53,976 --> 00:14:59,720 v0 is made of and in particular we're interested in the classed tag of v0 and 160 00:14:59,720 --> 00:15:05,095 we'll also be interested in the contents of its attributes. The locations 161 00:15:05,095 --> 00:15:10,781 associated with its attributes but first let's focus on the class tag. Alright, 162 00:15:10,781 --> 00:15:15,767 because we're going to use that class, remember, this is the dynamic type of the 163 00:15:15,767 --> 00:15:21,284 zeros and what kind of objects the zeros actually is when the program is running. 164 00:15:21,284 --> 00:15:27,067 And we're going to use that class to look up the definition of f that we should run. 165 00:15:27,067 --> 00:15:32,199 So, we look for the method f in class x. We want to know its implementation and in 166 00:15:32,199 --> 00:15:38,542 particular we get the names of the former parameters. Okay x1 through xn and we get 167 00:15:38,542 --> 00:15:45,695 the body of the function or method. Alright So, the next thing we have to do 168 00:15:45,695 --> 00:15:53,187 is we have to allocate space in the memory or in the store for the actual parameters 169 00:15:53,187 --> 00:15:59,587 of the method call. So, we allocate new locations. Okay, one for each actual 170 00:15:59,587 --> 00:16:05,586 argument and that we're ready to build an environment in which we can evaluate the 171 00:16:05,586 --> 00:16:10,238 method, alright? So, what is this environment going to consist of? So, we 172 00:16:10,238 --> 00:16:15,496 have to think about what names or in-scoped inside of a method. Well, all 173 00:16:15,496 --> 00:16:20,584 the attributes of the class are in-scope. Okay. So, this is a class x with 174 00:16:20,584 --> 00:16:25,642 attributes a1 through an so the environment will have those names to find 175 00:16:25,642 --> 00:16:30,290 a1 through an. And now what are the attributes or locations of those 176 00:16:30,290 --> 00:16:35,913 attributes. Well those are the locations of. The zero, that's the object that we're 177 00:16:35,913 --> 00:16:41,915 dispatching to that were going to be the self object and the attribute names will 178 00:16:41,915 --> 00:16:47,210 refer to the attributes of, of self, alright. So, those locations here are the 179 00:16:47,210 --> 00:16:53,423 locations of, of the attributes in the object v0. Now in addition the formal 180 00:16:53,423 --> 00:17:01,058 paramete rs are also in scope inside of the method body. So we add to this 181 00:17:01,058 --> 00:17:09,844 environment with just the attributes all of the formal parameters okay and they are 182 00:17:10,157 --> 00:17:16,605 at the new locations l(x1) up to l(xn). Okay? And notice one slight subtlety about 183 00:17:16,605 --> 00:17:22,590 the way this is defined we're taking an initial environment which I'll show here 184 00:17:22,590 --> 00:17:27,719 with, I'll, I'll color these braces in blue. So we're defining and initial 185 00:17:27,719 --> 00:17:33,063 environment of the attributes and then we're doing updates to that, okay? So 186 00:17:33,063 --> 00:17:39,190 we're, instead of just defining x1 to map two l sub x1, we're saying we're replacing 187 00:17:39,190 --> 00:17:45,354 The definition of x1 in this environment in the blue braces with one and maps x1 188 00:17:45,354 --> 00:17:50,986 and l(x1). Why do we do it that way? Well, the thing is that a method may have a 189 00:17:50,986 --> 00:17:57,303 formal parameter that is the same as an attribute name so for example I could have 190 00:17:57,303 --> 00:18:04,907 a class a that has an attribute little a in it And it also has a method f that 191 00:18:04,907 --> 00:18:11,680 takes a formal parameter named a. Okay And if I do that, and of course, I'm leaving 192 00:18:11,680 --> 00:18:15,666 out types and lots of other things here. So, here I have an attribute name 193 00:18:15,666 --> 00:18:19,870 [inaudible] that's declared. And then I have a method that takes the argument 194 00:18:19,870 --> 00:18:24,461 called a. And then the question is when I refer to a. Inside of the body of the 195 00:18:24,461 --> 00:18:30,188 method what a do I get? Is this a, is this a bind to the formal parameters, is it 196 00:18:30,188 --> 00:18:35,579 bind to the attribute? And the answer, we have to get one answer or the other, the 197 00:18:35,579 --> 00:18:41,238 answer in Kuhl, is that it binds to the formal parameter that hides the, the outer 198 00:18:41,238 --> 00:18:45,752 name. Okay, and that's, and that's enforced here in the rule by these 199 00:18:45,752 --> 00:18:51,075 updates. So, if a formal parameter has the same name as one of the attributes, it 200 00:18:51,075 --> 00:18:56,210 will replace the definition of the attribute in the environment. Okay. Once 201 00:18:56,210 --> 00:19:01,301 we get the environment set up, we need to set up our store what, what are the 202 00:19:01,301 --> 00:19:06,579 changes to the store? What we just have to store the actual value of each argument at 203 00:19:06,579 --> 00:19:11,785 the location for that argument. And finally, we are ready to evaluate the 204 00:19:11,785 --> 00:19:17,623 functioning body and the interesting part here is the context in which that's done. 205 00:19:17,623 --> 00:19:23,743 So, notice here that the that the self object in, in the context of running the 206 00:19:23,743 --> 00:19:28,143 method f is the object to which are dispatching. Okay? And then the 207 00:19:28,143 --> 00:19:32,293 environment is e prime, the new environment we just set up and once again 208 00:19:32,293 --> 00:19:36,841 notice that this is a complete change of context that e prime, the environment e 209 00:19:36,841 --> 00:19:41,105 prime has nothing to do with the environment e. E prime is built completely 210 00:19:41,105 --> 00:19:45,824 from scratch using only information about the method for calling, it doesn't borrow 211 00:19:45,824 --> 00:19:50,372 anything from the, from the environment where the method originated, where the 212 00:19:50,372 --> 00:19:56,298 method was called from. And finally all of this is done in the store that has, 213 00:19:56,298 --> 00:20:03,186 reflects all the side effects performed by evaluating the arguments, by evaluating e0 214 00:20:03,186 --> 00:20:09,749 and by extending the store with the locations for the actual parameters. So to 215 00:20:09,749 --> 00:20:16,393 evaluate the body of the method we get back a value and another updated store and 216 00:20:16,393 --> 00:20:23,200 that value in store are the results of the entire execution of the dynamic dispatch. 217 00:20:24,110 --> 00:20:29,296 To summarize our discussion of dynamic dispatch, the body of the method is 218 00:20:29,296 --> 00:20:35,037 invoked with, within environment e. That has definitions for the formal arguments 219 00:20:35,037 --> 00:20:40,655 and the attributes of the self object and a store that's just like color store 220 00:20:40,655 --> 00:20:46,204 except that it also has the actual arguments bound to the locations allocated 221 00:20:46,204 --> 00:20:51,617 for the formal parameters. Notice in the rules that the notion of a frame or 222 00:20:51,617 --> 00:20:56,990 activation records is implicit. We don't actually build a data structure. That 223 00:20:56,990 --> 00:21:01,337 contains you know, all of the values all of the arguments and the, the return 224 00:21:01,337 --> 00:21:05,960 address and all that stuff together. That information is not gathered together in 225 00:21:05,960 --> 00:21:10,363 one place, it's a little more abstract. We don't actually have to say you know, 226 00:21:10,363 --> 00:21:14,931 whether things are allocated on the stack or on the heat and that's a good feature. 227 00:21:14,931 --> 00:21:19,278 That allows us to have, potentially have a range of implementations like all 228 00:21:19,278 --> 00:21:23,925 implement the semantics correctly. Now, we didn't do the semantics on the semantics 229 00:21:23,925 --> 00:21:28,957 dispatch but it's extremely similar. The only difference is in how the class that 230 00:21:28,957 --> 00:21:33,525 we are going to be dispatching to is looked up so in the stack dispatch you 231 00:21:33,525 --> 00:21:38,036 might be able to you know, you can nam e the class that you want to dispatch to 232 00:21:38,036 --> 00:21:43,125 this one extra line to the side where the class is being dispatched to in the formal 233 00:21:43,125 --> 00:21:48,232 rule and you can look in the manual to see how that works. So it's worth pointing out 234 00:21:48,232 --> 00:21:53,489 that while the operation of rules are very detailed, they intentionally omit some 235 00:21:53,489 --> 00:21:58,811 cases that you might think they should cover so let's take a look at our dispatch 236 00:21:58,811 --> 00:22:05,808 example again. So here notice that we look up the class of v0. So v0 is an object and 237 00:22:05,808 --> 00:22:12,940 we checked what is class tag is and then we look up in that class, the name of the 238 00:22:12,940 --> 00:22:20,072 method that we're dispatching to and we get out a definition of the method or not 239 00:22:20,072 --> 00:22:27,291 the definition of the method that we can write the rest of the rule. Now what would 240 00:22:27,291 --> 00:22:33,582 happen If there was no such method f in the class x, I mean this, this rule just 241 00:22:33,582 --> 00:22:39,739 assumes that method is in fact to define the class x, And the rule doesn't say 242 00:22:39,739 --> 00:22:46,369 anything about what to do if it turns out that this class x doesn't have any method 243 00:22:46,369 --> 00:22:52,538 f? Well, that actually can't happen. So, type-checking has already guaranteed That 244 00:22:52,538 --> 00:22:58,064 when we go to look up method as in class x it will exist. That was one of the points 245 00:22:58,064 --> 00:23:03,523 with the type checking rules was that no dynamic dispatch could ever dispatch to a 246 00:23:03,523 --> 00:23:08,357 method that wasn't defined. And so the fact that the time checking is already 247 00:23:08,357 --> 00:23:12,857 been done, it will allows us to meet some cases. So there's some checks that we 248 00:23:13,030 --> 00:23:17,760 don't have to do because we know that, that system has already effectively done 249 00:23:17,760 --> 00:23:21,971 that And the rules would only be more complicated if we didn't have type 250 00:23:21,971 --> 00:23:26,413 checking and we needed to actually say what would happen you know, all of the 251 00:23:26,413 --> 00:23:32,638 cases where type checking will work where things were not typed correct. Now there 252 00:23:32,638 --> 00:23:38,557 are some run time errors that the type checker doesn't prevent however and in 253 00:23:38,557 --> 00:23:44,547 cool there are four. One is to dispatch the void. Divisions by zero you can have a 254 00:23:44,547 --> 00:23:49,603 sub-screen in that excess out of range or you could run out of memory. You could try 255 00:23:49,603 --> 00:23:54,418 allocating new objects that do not have enough space for that. And in such cases, 256 00:23:54,418 --> 00:23:59,474 the execution has to aboard gracefully an d that means with an error message and not 257 00:23:59,474 --> 00:24:04,590 just with a segmentation fault or some other kind of hard crash and in the manual 258 00:24:04,771 --> 00:24:10,007 there some guidelines as to what a correct co-implementation should do in this four 259 00:24:10,007 --> 00:24:15,707 situations. To summarize the material in the last couple of videos the operational 260 00:24:15,707 --> 00:24:21,312 semantic rules are really very precised and detail. If you understand them then 261 00:24:21,312 --> 00:24:26,988 you really understand how to implement a correct cool compiler. So the rules are 262 00:24:26,988 --> 00:24:33,019 complete enough and give you enough detail that it really can't go wrong if you just 263 00:24:33,019 --> 00:24:38,340 implement what the rules tell you to do. So you need to read the rules very 264 00:24:38,340 --> 00:24:42,957 carefully And I'll emphasize that because there's actually quite a lot going on in 265 00:24:42,957 --> 00:24:47,240 the rules. They're written in a certain way and you know, to, to achieve a certain 266 00:24:47,240 --> 00:24:51,415 effect and I pointed out a couple of subtle things in the rules and so you 267 00:24:51,415 --> 00:24:55,751 know, you really have to actually study the rules in order to internalize what 268 00:24:55,751 --> 00:25:00,011 they mean and be able to. Implement them correctly. It's also a great way 269 00:25:00,186 --> 00:25:05,270 understanding these rules and details was actually a great way to learn quite a bit 270 00:25:05,270 --> 00:25:09,945 of the, the kind of formal thinking that goes in to the design of programming 271 00:25:09,945 --> 00:25:14,327 languages and what it means for a programming language to have a semantics 272 00:25:14,327 --> 00:25:19,321 and for implementation of something to be correct. Now having settled that, I should 273 00:25:19,321 --> 00:25:23,754 say that most languages do not have a well specified operational semantics. There are 274 00:25:23,754 --> 00:25:28,136 some there are some substantial languages and fairly realistic languages that do 275 00:25:28,136 --> 00:25:32,361 have a formal semantics but most of the language is that you're familiar with do 276 00:25:32,361 --> 00:25:38,000 not. Finally just a comment you know [inaudible] is important when you really 277 00:25:38,000 --> 00:25:43,265 want software that you write behave the exactly the same in different environments 278 00:25:43,265 --> 00:25:48,403 so you know if I take the same program and I move it to a different machine or a 279 00:25:48,403 --> 00:25:53,541 different operating system and I still want to kind of guarantee that this offer 280 00:25:53,541 --> 00:25:59,123 will behave as it as it you know the same on both machine or the old environment and 281 00:25:59,123 --> 00:26:04,071 the new environment then I really need some independent defin ition of what it 282 00:26:04,071 --> 00:26:09,478 means what the behavior of these programs should be. And that's where a formal 283 00:26:09,478 --> 00:26:12,640 semantics becomes a really critical.