diff --git a/sicp.tmu b/sicp.tmu index 0cab43c178118dad207e11319ed3a29342b86210..ce0f39ac5d8e2c8c3a8079fcccb2a8ad096b0672 100644 --- a/sicp.tmu +++ b/sicp.tmu @@ -1,4 +1,4 @@ -> +> > @@ -4874,35 +4874,7 @@ A signal-processing engineer would find it natural to conceptualize these processes in terms of signals flowing through a cascade of stages, each of which implements part of the program plan, as shown in . In , we begin with an , which generates a “signal” consisting of the leaves of a given tree. This signal is passed through a , which eliminates all but the odd elements. The resulting signal is in turn passed through a , which is a “transducer” that applies the procedure to each element. The output of the map is then fed to an , which combines the elements using , starting from an initial 0. The plan for is analogous. <\big-figure> - <\script-output|dot|default> - digraph { - - \ \ rankdir=LR - - \ \ node [shape=box] - - \; - - \ \ "enumerate:\\ntree leaves" - - \ \ -\ "filter:\\nodd?" - - \ \ -\ "map:\\nsquare" - - \ \ -\ "accumulate:\\n+, 0" - - \ \ \ \ - - \ \ "enumerate:\\nintegers" - - \ \ -\ "map:\\nfib" - - \ \ -\ "filter:\\neven?" - - \ \ -\ "accumulate:\\ncons, ()" - - } - |ps>|0.618par|||>> + |png>|0.8par|0.25par||>> <|big-figure> The signal-flow plans for the procedures (top) and (bottom) reveal the commonality between the two programs. @@ -7567,7 +7539,9 @@ We begin with the simple complex-number example. We will see how type tags and data-directed style enable us to design separate rectangular and polar representations for complex numbers while maintaining the notion of an abstract “complex-number” data object. We will accomplish this by defining arithmetic procedures for complex numbers (, , , and ) in terms of generic selectors that access parts of a complex number independent of how the number is represented. The resulting complex-number system, as shown in , contains two different kinds of abstraction barriers. The “horizontal” abstraction barriers play the same role as the ones in . They isolate “higher-level” operations from “lower-level” representations. In addition, there is a “vertical” barrier that gives us the ability to separately design and install alternative representations. - <\big-figure||png>|200pt|||>> + <\big-figure> + |png>|0.8par|0.334par||>> + <|big-figure> Data-abstraction barriers in the complex-number system. @@ -7873,7 +7847,11 @@ \ \ (make-from-mag-ang-polar r a)) - <\big-figure||png>|0.618par|||>> + <\big-figure> + \; + + |png>|0.8par|0.390444par||> + <|big-figure> Structure of the generic complex-arithmetic system. @@ -8207,7 +8185,7 @@ shows the structure of the system we shall build. Notice the abstraction barriers. From the perspective of someone using “numbers,” there is a single procedure that operates on whatever numbers are supplied. is part of a generic interface that allows the separate ordinary-arithmetic, rational-arithmetic, and complex-arithmetic packages to be accessed uniformly by programs that use numbers. Any individual arithmetic package (such as the complex package) may itself be accessed through generic procedures (such as ) that combine packages designed for different representations (such as rectangular and polar). Moreover, the structure of the system is additive, so that one can design the individual arithmetic packages separately and combine them to produce a generic arithmetic system. - <\big-figure||png>|0.618par|||>> + <\big-figure||png>|407pt|236pt||>> Generic arithmetic system. @@ -8567,25 +8545,7 @@ The coercion scheme presented above relied on the existence of natural relations between pairs of types. Often there is more “global” structure in how the different types relate to each other. For instance, suppose we are building a generic arithmetic system to handle integers, rational numbers, real numbers, and complex numbers. In such a system, it is quite natural to regard an integer as a special kind of rational number, which is in turn a special kind of real number, which is in turn a special kind of complex number. What we actually have is a so-called , in which, for example, integers are a of rational numbers (i.e., any operation that can be applied to a rational number can automatically be applied to an integer). Conversely, we say that rational numbers form a of integers. The particular hierarchy we have here is of a very simple kind, in which each type has at most one supertype and at most one subtype. Such a structure, called a , is illustrated in . - <\big-figure|<\script-output|dot|default> - %dot -height 240px - - digraph G { - - \ \ \ \ rankdir=DT - - \ \ \ \ node [shape=plaintext] - - \ \ \ \ - - \ \ \ \ integer -\ rational - - \ \ \ \ rational -\ real - - \ \ \ \ real -\ complex - - } - |ps>||240px||>>> + <\big-figure||png>||4cm||>> A tower of types. @@ -8603,45 +8563,7 @@ 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. 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 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 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. - <\big-figure|<\script-output|dot|default> - digraph G { - - \ \ node [shape=plaintext] - - \ \ polygon -\ triangle - - \ \ triangle -\ "right triangle" - - \ \ triangle -\ "isosceles triangle" - - \ \ "right triangle" -\ "isosceles right triangle" - - \ \ "isosceles triangle" -\ "isosceles right triangle" - - \ \ "isosceles triangle" -\ "equilateral triangle" - - \ \ \ \ - - \ \ polygon -\ quadrilateral - - \ \ quadrilateral -\ trapezoid - - \ \ quadrilateral -\ kite - - \ \ trapezoid -\ parallelogram - - \ \ parallelogram -\ rectangle - - \ \ parallelogram -\ chombus - - \ \ rectangle -\ square - - \ \ kite -\ chombus - - \ \ chombus -\ square - - } - |ps>|0.618par|||>>> + <\big-figure||png>|0.8par|0.559274par||>> Relations among types of geometric figures. @@ -9493,6 +9415,7 @@ +