[1] We also have to supply an almost identical procedure function to handle the types (scheme_number complex). list("javascript_number", "complex").
[2] See exercise 2.86 for generalizations.
[3] If we are clever, we can usually get by with fewer than $n^2$ coercion procedures. functions. For instance, if we know how to convert from type 1 to type 2 and from type 2 to type 3, then we can use this knowledge to convert from type 1 to type 3. This can greatly decrease the number of coercion procedures functions we need to supply explicitly when we add a new type to the system. If we are willing to build the required amount of sophistication into our system, we can have it search the graph of relations among types and automatically generate those coercion procedures functions that can be inferred from the ones that are supplied explicitly.
[4] This statement, which also appears in the first edition of this book, is just as true now as it was when we wrote it twelve years ago. in 1984. Developing a useful, general framework for expressing the relations among different types of entities (what philosophers call ontology) seems intractably difficult. The main difference between the confusion that existed ten years ago in 1984 and the confusion that exists now is that now a variety of inadequate ontological theories have been embodied in a plethora of correspondingly inadequate programming languages. For example, much of the complexity of object-oriented programming languages—and the subtle and confusing differences among contemporary object-oriented languages—centers on the treatment of generic operations on interrelated types. Our own discussion of computational objects in chapter 3 avoids these issues entirely. Readers familiar with object-oriented programming will notice that we have much to say in chapter 3 about local state, but we do not even mention classes or inheritance. In fact, we suspect that these problems cannot be adequately addressed in terms of computer-language design alone, without also drawing on work in knowledge representation and automated reasoning.
[5] A real number can be projected to an integer using the round math_round primitive, which returns the closest integer to its argument.
2.5.2   Combining Data of Different Types