sicpsgjd/3/1/jord/notes.org

• 3.1 assignment and local state
  • 3.1.1 local state variables
  • 3.1.2 the benefits of introducing assignment
  • 3.1.3 the costs of introducing assignment

Chapter 3: Modularity, Objects, and State

so far we have reviewed the primitive elements of how programs are made and how those primitive elements can be combined in complex ways.

we learned the value of abstraction and modular programs.

modular

the nature of a program thot it can be divided "naturally" into coherent parts that can be separately developed and maintained

we now look towards how to design entire systems. we will look at two prominent strategies for program construction:

objects

seeing a program as a collection of distinct objects whose behaviors may change over time

streams

seeing a program as a flow of information in a system

we will finally discard the substitution model of chapter 1 in favor of the environment model

3.1 assignment and local state

we ordinarily view the world as a collection of independent objects each of which has state that changes over time.

at this point (in ch 3!!!) we will discuss local state variables and the assignment operator

3.1.1 local state variables

we now have a comptational object with time-varying state

this means:

(withdraw 25) --> 75
(withdraw 25) --> 25
(withdraw 60) --> "Insufficient Funds"
(withdraw 15) --> 35

these are not pure funtions

when evaluated twice, they yield different results

this is new before, we computed mathematical functions

  (define balance 100)

  (define (withdraw amount)
    (if (>= balance amount)
	(begin (set! balance (- balance amount))
	       balance)
	"Insufficient Funds"))

we have the new language features, set! which sets a new value to a variable:

(set! name new-value)

and we have the (begin … … …) form, which returns the value of its final expression

there's some trouble with that begin variable. we can make it internal by encapsulating it:

  (define new-withdraw
    (let ((balance 100))
      (lambda (amount)
	(if (>= balance amount)
	    (begin (set! balance (- balance amount))
		   balance)
	    "Insufficient Funds"))))

combining set! with local variables is the general technique for constructing computational objects.

–> here we have just annhialated our substitution model. according to it, the above is incomprehensible. we will address later. first, a few variations on this new and very exciting theme

  (define (make-withdraw balance)
    (lambda (amount)
      (if (>= balance amount)
	  (begin (set! balance (- balance amount))
		 balance)
	  "Insufficient Funds")))

make-withdraw

which can be used to make accounts with custom amounts

  (define W1 (make-withdraw 100))
  (define W2 (make-withdraw 100))
  (W1 50)
  (W2 70)

30

these two withdrawal accounts are independent of each other

to make a functional bank account:

  (define (make-account balance)
    (define (withdraw amount)
      (if (>= balance amount)
	  (begin (set! balance (- balance amount))
		 balance)
	  "Insufficient Funds"))
    (define (deposit amount)
      (set! balance (+ balance amount))
      balance)
    (define (dispatch m)
      (cond ((eq? m 'withdraw) withdraw)
	    ((eq? m 'deposit) deposit)
	    (else (error "Unknown request -- MAKE-ACCOUNT"
			 m))))
    dispatch)

make-account

and to use it:

  (define acc (make-account 100))
  ((acc 'withdraw) 25)
  ((acc 'withdraw) 80)
  ((acc 'deposit) 120)
  ((acc 'withdraw) 60)

135

and:

  (define acc2 (make-account 100))

acc2

will be a completely different account

3.1.2 the benefits of introducing assignment

with assignment, we can encapsulate state, rather than injecting it via formal parameters all over the place.

3.1.3 the costs of introducing assignment

set! is cool, but it breaks the substitution model.

it breaks all "nice" mathematical models.

the reason it doesnt work is variable scope. like closures, i think. or like the kind of closure this book said is the wrong thing.

functional programming

as we did in the first two chapters of the book, to not use assignment

imperative programming

makes extensive use of assignment

SAMENESS AND CHANGE

referentially transparent

"equals can be substituted for equals" without changing the value of an expression

set! violates referential transparency.