Notes from 11/1/02

- symbols, names, variables --- (via enviroment) ---> values
	- way we've been thinking about it before
	- functional programming

- symbols, names -- (via enviroment) --> variables -- (via state) --> values
	- new way
	- procedural, state-modifying programming
	- variables also called addresses, places, pointer values, l-values

- actions
	- binding is associating symbol -> variable
	- assigning is associating variable -> value

- read 3.2 to get an idea of eviroment/frame implementation

- discussion of enviroment/state modifications
	- (lambda (x) body)
		- build a procedure to evaluate body in an enviroment that extends the current one with a frame for x

	- (procedure arg)
		- create a new enviroment that is enclosed in the enviroment of that procedure
		- has a new frame binding symbols to new variable
		- assigning the value of arg in the current enviroment to that new variable
		- evaluate body in new enviroment

	- (define var arg)
		- if var is unbound, add a new variable to current enviroment (current frame, actually)
		- bind var to it
		- if var is already bound, start here
		- so then for either case, assign the value of arg in current enviroment to the variable bound to var

	- (define var)
		- just binds a new variable to var
		- if var is already bound, still binds a new variable
		- loses old assignment

	- (set! var arg)
		- only assigns value of arg in current enviroment to variable bound to var
		- complains if var is unbound

	- (let ...)
		- since this is a special lambda form, think through the lambda rules for this

- (begin x1 x2 ... xn)
	- used to evaluate x1...xn-1
	- returns the value of xn
	- used to evaluate a string of things for their side-effects
		- like (set! ...)
		- since set! doesn't have a return value
	- usual use is either all 'side-effect' calls, or all but the last, and make the last functional