6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology The concept of a tag Slide 9.1.16 Tagged data This simple example thus motivates the key idea we are going to attach an identifying symbol to all nontrivial data values explore in this lecture: by putting tags on data structures, we can identify the right operations to apply to that data structure. In define ( make-poant x y) (ist "point x y) fact, a careful programmer would always put tags on data system, and to provide a means verifying that correct operations are being applied to data Thus, tagged data now refers to the concept of attaching an ing label to all non-trivial data types in my 6001 SICP convention, we will try to always check the label on the data structure before applying any procedures to manipulate those structures Slide 9.1.17 Benefits of tagged data As we will see, there are two key reasons for wanting to use tagged data. The first is that it makes available to use the functions that decide what to do based on the arguments owerful idea of data directed programming. Here, the idea to let the type of an object direct the procedure to the right cample: in a graphics program area: triangle square -> number method to apply to that type of object. This means that our style will be to write procedures that look at the type of the argument, and use that information to apply a procedure specifically tuned to that type of object. This, in fact, is exactly what we just did ith complex numbers. In that case, the selectors used the data type to direct the system to the right method 6001 sICP another example, suppose you are writing a graphics program, and want to be able to compute the area of a figure Rather than writing one giant procedure to do this for all types of figures, we could let the type of the figure(a triangle, a square, some other form) direct the procedure to a subprocedure specifically designed for that type of figure. Such an approach leads to very modular code, which is much easier to modify and maintain Benefits of tagged data Slide 91.18 data-directed programming The second key reason is that this approach allows us to practice functions that decide what to do based on the arguments defensive programming. We want to be careful to ensure that we don't have unwarranted assumptions about inputs to our area: triangle square l circle - number procedures, and in particular, we want our procedures to fail gracefully when they unexpected receive inputs of the wrong type. As we saw in the previous example, when we created a selector for a complex number, we did exactly that. I checked .much better to give an error message than for specific types of objects, specifying the method to use, but if I did not recognize the type of the object as something I was set to handle, I returned an error message with appropriate debug code if the error doesn't show up until several stages of additional processing have been applied to thay s 6001 SICP information. The point is that by handling unknown types rather than assuming something about a data object, we catch errors before they can propagate. It is much harder to incorrect data type6.001 Structure and Interpretation of Computer Programs. Copyright © 2004 by Massachusetts Institute of Technology. Slide 9.1.16 This simple example thus motivates the key idea we are going to explore in this lecture: by putting tags on data structures, we can identify the right operations to apply to that data structure. In fact, a careful programmer would always put tags on data structures, exactly to provide the flexibility to extend his or her system, and to provide a means verifying that correct operations are being applied to data. Thus, tagged data now refers to the concept of attaching an identifying label to all non-trivial data types in my system. By convention, we will try to always check the label on the data structure before applying any procedures to manipulate those structures. Slide 9.1.17 As we will see, there are two key reasons for wanting to use tagged data. The first is that it makes available to use the powerful idea of data directed programming. Here, the idea is to let the type of an object direct the procedure to the right method to apply to that type of object. This means that our style will be to write procedures that look at the type of the argument, and use that information to apply a procedure specifically tuned to that type of object. This, in fact, is exactly what we just did with complex numbers. In that case, the selectors used the data type to direct the system to the right method. As another example, suppose you are writing a graphics program, and want to be able to compute the area of a figure. Rather than writing one giant procedure to do this for all types of figures, we could let the type of the figure (a triangle, a square, some other form) direct the procedure to a subprocedure specifically designed for that type of figure. Such an approach leads to very modular code, which is much easier to modify and maintain. Slide 9.1.18 The second key reason is that this approach allows us to practice defensive programming. We want to be careful to ensure that we don't have unwarranted assumptions about inputs to our procedures, and in particular, we want our procedures to fail gracefully when they unexpected receive inputs of the wrong type. As we saw in the previous example, when we created a selector for a complex number, we did exactly that. I checked for specific types of objects, specifying the method to use, but if I did not recognize the type of the object as something I was set to handle, I returned an error message with appropriate information. The point is that by handling unknown types here, rather than assuming something about a data object, we catch errors before they can propagate. It is much harder to debug code if the error doesn't show up until several stages of additional processing have been applied to that incorrect data type