6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology 6.001 Notes: Section 6.1 Slide 6.1.1 Types When we first starting talking about Scheme expressions, you may recall we said that(almost )every Scheme expression had three components, a syntax (legal ways of gluing things together ) a semantics(a way of deciding the meanin associated with an expression), and a type. We haven't said much about types yet. Today we are going to look in more detail at types, and especially how we can use types to design procedures with different kinds of behaviors 60015e Types Slide 6.1.2 So let's motivate the idea of a type. Consider the following two examples. The first expression we know will correctly add the i The object hi", passed as the first argument to integer-add not the correct two numbers to get 15. The second expression we expect to type give an error, since while we may like to get "high fives",we know that we can't add a string to a number, as addition is only used on numbers Note what this implies. It suggests that the addition procedure has associated with it an expectation of what kinds of arguments it will get, in particular an expectation about the type of each argument, in this case, numbers Slide 6.1.3 perform its job since it was not given what it expected an of an/Types And here, since we have given a string as an input, instead (+510)=>1 integer, the procedure should complain, stating that it ca i The object"hi", passed as the first argument to integer-add, is not the correct Addition is not defined for strings6.001 Structure and Interpretation of Computer Programs. Copyright © 2004 by Massachusetts Institute of Technology. 6.001 Notes: Section 6.1 Slide 6.1.1 When we first starting talking about Scheme expressions, you may recall we said that (almost) every Scheme expression had three components, a syntax (legal ways of gluing things together), a semantics (a way of deciding the meaning associated with an expression), and a type. We haven't said much about types yet. Today we are going to look in more detail at types, and especially how we can use types to design procedures with different kinds of behaviors. Slide 6.1.2 So let's motivate the idea of a type. Consider the following two examples. The first expression we know will correctly add the two numbers to get 15. The second expression we expect to give an error, since while we may like to get "high fives", we know that we can't add a string to a number, as addition is only used on numbers. Note what this implies. It suggests that the addition procedure has associated with it an expectation of what kinds of arguments it will get, in particular an expectation about the type of each argument, in this case, numbers. Slide 6.1.3 And here, since we have given a string as an input, instead of an integer, the procedure should complain, stating that it can't perform its job since it was not given what it expected