From e72fb7481bddf8b1169fb9a351e08704a8366f91 Mon Sep 17 00:00:00 2001 From: Da Shen Date: Sat, 4 Jul 2026 15:42:45 +0800 Subject: [PATCH 1/3] wip --- sicp.tmu | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sicp.tmu b/sicp.tmu index 0cab43c..56fc1f9 100644 --- a/sicp.tmu +++ b/sicp.tmu @@ -1,4 +1,4 @@ -> +> > @@ -9493,6 +9493,7 @@ + -- Gitee From 79ff1b5596e740444f31637f17ed0c4837414101 Mon Sep 17 00:00:00 2001 From: Da Shen Date: Sat, 4 Jul 2026 17:54:19 +0800 Subject: [PATCH 2/3] =?UTF-8?q?=E8=B0=83=E6=95=B4=E9=85=8D=E5=9B=BE?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- sicp.tmu | 102 +++++++------------------------------------------------ 1 file changed, 12 insertions(+), 90 deletions(-) diff --git a/sicp.tmu b/sicp.tmu index 56fc1f9..06c06f5 100644 --- a/sicp.tmu +++ b/sicp.tmu @@ -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>|49pt|170pt||>> 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. -- Gitee From 40dcfe83577286f796f0edd8fbcd6f454083df98 Mon Sep 17 00:00:00 2001 From: Da Shen Date: Sat, 4 Jul 2026 18:07:07 +0800 Subject: [PATCH 3/3] wip --- sicp.tmu | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sicp.tmu b/sicp.tmu index 06c06f5..ce0f39a 100644 --- a/sicp.tmu +++ b/sicp.tmu @@ -8545,7 +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||png>|49pt|170pt||>> + <\big-figure||png>||4cm||>> A tower of types. -- Gitee