《SICP》读书笔记--Chapter 3 Modularity, Objects and State

Chapter 3 Modularity, Objects, and State

Modularity, divide system to coherent parts that can be separately developed and maintained.

How to modularity?

Two prominent organizational strategies arising from two rather different "world views" of the structure of systems.

objects: viewing a large system as a collection of distinct objects whose behaviors may change over time.

object can be change, maintain identity. abandon old substitution model of computation in a favor of a more mechanistic but less theoretically tractableenvironment model of computation. difficulties on concurrent programming.

streams: stream of information that flow in the system, much as an electrical engineer views of signal-processing system.decouple simulated time in our model from the order of the events that take place in the computer during evaluation. delayed evaluation

两个中间应该选择哪个呢？选择的方法是什么？

3.1 Assignment and Local State

the view that a system is composed of separate objects is most useful when the state variables of the system can be grouped into closely coupled subsystems that are only loosely coupled to other subsystems.

3.1.1 Local State Variable

3.1.2 The Benefits of Introducing Assignment

maintaining a modular design. By introducing assignment and the technique of hiding state in local variables, we are able to structure systems in a more modular fashion than if all state had to be manipulated explicitly, by passing additional parameters.

3.1.3 The Cost of Introducing Assignment

Substitution model not work any more. Before:Functional programming

Sameness and Change

Pitfalls of imperative programming

Imperative Programming: programming that makes extensive use of assignment is known as imperative programming.

carefully consider the relative orders of the assignments to make sure that each statement is using the correct version of the variables that have been changed. This not arise in functional programming.(especially in concurrent)

3.2 The Environment Model of Evaluation

Recall:

substitution model of evaluation: To apply a compound procedure to arguments, evaluate the body of the procedure with each form parameter replaced by the corresponding argument.

Variable can no longer be considered to be merely a name for a value. Rather, a variable must somehow designate a "place" in which values can be stored. In our new model of evaluation, these places will be maintained in structures called environment.

Environment is a sequence of frames. Each frame is a table ofbindings. Each frame also has a pointer to its enclosing environment.(封闭环境)

Environment is the context in which an expression should be evaluated.

3.2.1 The Rules for Evaluation

To evaluate a combination:

1. Evaluate the subexpressions of the combination

2. Apply the value of the operator subexpression to the values of the operand subexpressions.

some code with a pointer to the environment: one only way. evaluating alambda expression. This produces a procedure whose code is obtained from the text of the lambda expression and whose environment is the environment in which the lambda expression was evaluated.

How procedure are created

(define (square x) (* x x)) ==equivalent==> (define (square x) (lambda (x) (* x x)))

global env [square: { parameters: x, body: (* x x)}]

How procedure are applied

To apply a procedure to arguments, createa new environment containing a frame that binds the parameters to the values of the arguments. The enclosing environment of this frame is the environment specified by the procedure. Now, within this new environment, evaluate the procedure body.

3.2.2 Applying Simple Procedures [*]

3.2.3 Frames as the Repository of Local State

3.2.4 Internal Definitions

3.3 Modeling with Mutable Data

Mutation is just assignment

3.3.1 Mutable List Structure

3.3.2 Representing Queues

3.3.5 propagation with constraints

3.4 Concurrency: Time Is of the Essence

Building models in terms of computational objects with local state forces us to confront time as an essential concept in programming

3.4.1 The Nature of Time in Concurrent Systems

Correct Behavior of concurrent programs

Extremely stringent: no two operations that changeany shared state variables can occur at the same time

Less stringent: ensure that a concurrent system produces the same result as if the processes had run sequentially in order.[NOT require the processes to actually run sequentially, but the results are same]

concurrent programs are inherently nondeterministic.

3.4.2 Mechanisms for Controlling Concurrency

serializer

Serializing access to shared state:Processes will execute concurrently, but there will be certain collections of procedures that cannot be executed concurrently(Single Shared Resource)

Complexity of using multiple shared resources

Concurrency, time and communication

the problems of concurrency lie deeper than this, because, from a fundamental point of view, it's not always clear what is meant by "shared state"????

barrier synchrnozation??

The complexities we encounter in dealing with time and state in our computational models may in fact mirror a fundamental complexity of the physical universe.

3.5 Streams

Review the complexity of model local state: 

We modeled real-world objects with local state by computational objects with local variables. 

We identified time variation in the real world with time variation in the computer. 

We implemented the time variation of the states of the model objects in the computer with assignments to the local variables of the model objects.

Another Approach? 

Can we avoid identifying time in the computer with time in the modeled world? Must we make the model change with time in order to model phenomena in a changing world? 

If time is measured in discrete steps, then we can model a time function as a (possibly infinite) sequence.

a Stream is simply a sequence.

3.5.1 Streams Are Delayed Lists

If we represent sequences as list, inefficiency with respect to both the time and space required by our computations. (copy data)

delayed object: (delay <exp>), a "promise" to evaluate <exp> at some future time.force takes a delayed object as argument and performs the evaluation.

(cons-stream <a> <b>)   <==>   (cons <a> (delay <b>))

(define (stream-car stream) (car stream))

(define (stream-cdr stream) (force (cdr stream)))

Implementing delay and force

(delay <exp>) <==> (lambda () <exp>)

(define (force delayed-object) (delayed-object))

3.5.2 Infinite Streams

3.5.3 Exploiting the Stream Paradigm

Formulating iterations as stream processes

3.5.5 Modularity of Functional Programs and Modularity of Objects

A functional-programming view of time[VERY IMPORTANT]

Event through stream-withdraw implements a well-defined mathematical function whose behvaior does not change, the user's perception here is one of interacting with a system that has a changing state. One way to resolve this paradox(悖论，似是而非) is to realize that it is the user's temporal existence that imposes state on the system. If the user could step back from the interaction and think in terms of streams of balances rather than individual transactions, the system would appear stateless.

[NOTE: Similarity in physics, when we observe a moving particle, we say that the position(state) of the particle is changing. However, from the perspective of the particle's world line in space-time there is no change involved]

We can see time-related problems creeping into functional models as well. One particularly troublesome area arises when we wish to design interactive systems, especially ones that model interactions between independent entities.

注解75