(define self-add
(let ((x 0))
(lambda ()
(set! x (+ x 1))
x)))
(self-add) => 1
(self-add) => 2
(self-add) => 3
(self-add) => 4
2.
(define self-add1
(lambda ()
(let ((x 0))
(set! x (+ x 1))
x)))
(self-add1) => 1
(self-add1) => 1
(self-add1) => 1
Please tell me how to understand the difference between the above two functions?
Thanks a lot in advance!
Best regards.
The first function defines a local variable x with an initial value of 0 and afterwards binds a lambda special form to the name self-add - so x is "enclosed" by the lambda (that's why we say that the lambda from behaves as a closure) and will be the same for all invocations of self-add (you could say that x is "remembered" by self-add), and each time it gets called the value of x will be incremented by one.
The second function binds the lambda to the procedure and afterwards defines a local variable x inside the lambda - here x is redefined each time self-add1 gets called, and will be different for all invocations: so x is never "remembered" by self-add1 and is created anew every time the procedure gets called, initialized with 0 and then incremented, always returning the value 1.
The first function is closure. You create x variable in the lexical scope of the function and the variable holds its value between calls.
Additional information:
http://en.wikipedia.org/wiki/Closure_(computer_science)
What is lexical scope?
First function is a closure, while second function simply returns the same function every time, which makes x = 0 and then adds one and returns the result.
Related
I am a little confused on how the environment model of evaluation works, and hoping someone could explain.
SICP says:
The environment model specifies: To apply a procedure to arguments,
create a 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.
First example:
If I:
(define y 5)
in the global environment, then call
(f y)
where
(define (f x) (set! x 1))
We construct a new environment (e1). Within e1, x would be bound to the value of y (5). In the body, the value of x would now be 1. I found that y is still 5. I believe the reason for this is because x and y are located in different frames. That is, I completely replaced the value of x. I modified the frame where x is bound, not just its value. Is that correct?
Second example:
If we have in the global environment:
(define (cons x y)
(define (set-x! v) (set! x v))
(define (set-y! v) (set! y v))
(define (dispatch m)
(cond ((eq? m 'car) x)
((eq? m 'cdr) y)
((eq? m 'set-car!) set-x!)
((eq? m 'set-cdr!) set-y!)
(else (error "Undefined
operation: CONS" m))))
dispatch)
(define (set-car! z new-value)
((z 'set-car!) new-value)
z)
Now I say:
(define z2 (cons 1 2))
Suppose z2 has a value the dispatch procedure in an environment called e2, and I call:
(set-car! z2 3)
Set-car! creates a new environment e3. Within e3, the parameter z is bound to the value of z2 (the dispatch procedure in e2) just like in my first example. After the body is executed, z2 is now '(3 2). I think set-car! works the way it does is because I am changing the state of the object held by z (which is also referenced by z2 in global), but not replacing it. That is, I did not modify the frame where z is bound.
In this second example it appears that z2 in global and z in e3 are shared. I am not sure about my first example though. Based on the rules for applying procedures in the environment model, it appears x and y are shared although it is completely undetectable because 5 does not have local state.
Is everything I said correct? Did I misunderstood the quote?
To answer your first question: assuming that you meant to write (f y) in your first question rather than (f 5), the reason that y is not modified is that racket (like most languages) is a "call by value" language. That is, values are passed to procedure calls. In this case, then the argument y is evaluated to 5 before the call to f is made. Mutating the x binding does not affect the y binding.
To answer your second question: in your second example, there are shared environments. That is, z is a function that is closed over an environment (you called it e2). Each call to z creates a new environment that is linked to the existing e2 environment. Performing mutation on either x or y in this environment affects all future references to the e2 environment.
Summary: passing the value of a variable is different from passing a closure that contains that variable. If I say
(f y)
... the after the call is done, 'y' will still refer to the same value[*]. If I write
f (lambda (...) ... y ...)
(that is, passing a closure that has a reference to y, then y might be bound to a different value after the call to f.
If you find this confusing, you're not alone. The key is this: don't stop using closures. Instead, stop using mutation.
[*] if y is a mutable value, it may be mutated, but it will still be the "same" value. see note above about confusion.
TL;DR: simple values in Scheme are immutable, are copied in full when passed as arguments into functions. Compound values are mutable, are passed as a copy of a pointer, whereas the copied pointer points to the same memory location as the original pointer does.
What you're grappling with is known as "mutation". Simple values like 5 are immutable. There's no "set-int!" to change 5 to henceforth hold the value 42 in our program. And it is good that there isn't.
But a variable's value is mutable. A variable is a binding in a function invocation's frame, and it can be changed with set!. If we have
(define y 5)
(define (foo x) (set! x 42) (display (list x x)))
(foo 5)
--> foo is entered
foo invocation environment frame is created as { x : {int 5} }
x's binding's value is changed: the frame is now { x : {int 42} }
(42 42) is displayed
y still refers to 5 in the global environment
But if foo receives a value that is itself holding mutable references, which can be mutated, i.e. changed "in place", then though foo's frame itself doesn't change, the value to which a binding in it is referring can be.
(define y (cons 5 6)) ; Scheme's standard cons
--> a cons cell is created in memory, at {memory-address : 123}, as
{cons-cell {car : 5} {cdr : 6} }
(define (foo x) (set-car! x 42) (display (list x x)))
(foo y)
--> foo is entered
foo invocation environment frame is created as
{ x : {cons-cell-reference {memory-address : 123}} }
x's binding's value is *mutated*: the frame is still
{ x : {cons-cell-reference {memory-address : 123}} }
but the cons cell at {memory-address : 123} is now
{cons-cell {car : 42} {cdr : 6} }
((42 . 6) (42 . 6)) is displayed
y still refers to the same binding in the global environment
which still refers to the same memory location, which has now
been altered in-place: at {memory-address : 123} is now
{cons-cell {car : 42} {cdr : 6} }
In Scheme, cons is a primitive which creates mutable cons cells which can be altered in-place with set-car! and set-cdr!.
What these SICP exercises intend to show is that it is not necessary to have it as a primitive built-in procedure; that it could be implemented by a user, even if it weren't built-in in Scheme. Having set! is enough for that.
Another jargon for it is to speak of "boxed" values. If I pass 5 into some function, when that function returns I'm guaranteed to still have my 5, because it was passed by copying its value, setting the function invocation frame's binding to reference the copy of the value 5 (which is also just an integer 5 of course). This is what is referred to as "pass-by-value".
But if I "box" it and pass (list 5) in to some function, the value that is copied -- in Lisp -- is a pointer to this "box". This is referred to as "pass-by-pointer-value" or something.
If the function mutates that box with (set-car! ... 42), it is changed in-place and I will henceforth have 42 in that box, (list 42) -- under the same memory location as before. My environment frame's binding will be unaltered -- it will still reference the same object in memory -- but the value itself will have been changed, altered in place, mutated.
This works because a box is a compound datum. Whether I put a simple or compound value in it, the box itself (i.e. the mutable cons cell) is not simple, so will be passed by pointer value -- only the pointer will be copied, not what it points to.
x bound to the value of y means that x is a new binding which receives a copy of the same value that y contains. x and y are not aliases to a shared memory location.
Though due to issues of optimization, bindings are not exactly memory locations, you can model their behavior that way. That is to say, you can regard an environment to be a bag of storage locations named by symbols.
Educational Scheme-in-Scheme evaluators, in fact, use association lists for representing environments. Thus (let ((x 1) (y 2)) ...) creates an environment which simply looks like ((y . 1) (x . 2)). The storage locations are the cdr fields of the cons pairs in this list, and their labels are the symbols in the car fields. The cell itself is the binding; the symbol and location are bound together by virtue of being in the same cons structure.
If there is an outer environment surrounding this let, then these association pairs can just be pushed onto it with cons:
(let ((z 3))
;; env is now ((z . 3))
(let ((x 1) (y 2))
;; env is now ((y . 2) (x . 1) (z . 3))
The environment is just a stack of bindings that we push onto. When we capture a lexical closure, we just take the current pointer and stash it into the closure object.
(let ((z 3))
;; env is now ((z . 3))
(let ((x 1) (y 2))
;; env is now ((y . 2) (x . 1) (z . 3))
(lambda (a) (+ x y z a))
;; lambda is an object with these three pices:
;; - the environment ((y . 2) (x . 1) (z . 3))
;; - the code (+ x y z a)
;; - the parameter list (a)
)
;; after this let is done, the environment is again ((z . 3))
;; but the above closure maintains the captured one
)
So suppose we call that lambda with an argument 10. The lambda takes the parameter list (a) and binds it to the argument list to create a new environment:
((a . 1))
This new environment is not made in a vacuum; it is created as an extension to the captured environment. So, really:
((a . 1) (y . 2) (x . 1) (z . 3))
Now, in this effective environment, the body (+ x y z a) is executed.
Everything you need to understand about environments can be understood in reference to this cons pair model of bindings.
Assignment to a variable? That's just set-cdr! on a cons-based binding.
What is "extending an environment"? It's just pushing a cons-based binding onto the front.
What is "fresh binding" of a variable? That's just the allocation of a new cell with (cons variable-symbol value) and extending the environment with it by pushing it on.
What is "shadowing" of a variable? If an environment contains (... ((a . 2)) ...) and we push a new binding (a . 3) onto this environment, then this a is now visible, and (a . 2) is hidden, simply because the assoc function searches linearly and finds (a . 2) first! The inner-to-outer environment lookup is perfectly modeled by assoc. Inner bindings appear to the left of outer bindings, closer to the head of the list and are found first.
The semantics of sharing all follow from the semantics of these lists of cells. In the assoc list model, environment sharing occurs when two environment assoc lists share the same tail. For instance, each time we call our lambda above, a new (a . whatever) argument environment is created, but it extends the same captured environment tail. If the lambda changes a, that is not seen by the other invocations, but if it changes x, then the other invocations will see it. a is private to the lambda invocation, but x, y and z are external to the lambda, in its captured environment.
If you fall back on this assoc list model mentally, you will not go wrong as far as working out the behavior of environments, including arbitrarily complex situations.
Real implementations basically just optimize around this. for instance, a variable that is initialized from a constant like 42 and never assigned does not have to exist as an actual environment entry at all; the optimization called "constant propagation" can just replace occurrences of that variable with 42, as if it were a macro. Real implementations may use hash tables or other structures for the environment levels, not assoc lists. Real implementations may be compiled: lexical environments can be compiled according to various strategies such as "closure conversion". Basically, an entire lexical scope can be flattened into a single vector-like object. When a closure is made at run time, the entire vector is duplicated and initialized. Compiled code doesn't refer to variable symbols, but to offsets in the closure vector, which is substantially faster: no linear search through an assoc list is required.
hy everyone, for school i have to make a function where lambda is used as a parameter
like so : (string (lambda ...) 5 40) where we have to fill in the dots
this is the function we had to reinvent, the regular string version
(define (string decoration n r) >string decoration is a function that creates a string with either fish or pumpkins hanging on the string
(define (decorations k) >decorations is the recursive function which hangs all the decorations together
(if (= k 1)
(decoration r 10) > here decoration is to be replaced with either a pumpkin or a fish as stated in the parameters
(ht-append (decoration r 10) > ht-append is a function that appends 2 figures Horizontally at the Top
(decorations (- k 1)))))
(hang-by-thread (decorations n))) > hang by thread is a function that hangs all the decorations at a string
all the names should be self-explanatory, the function takes a decoration , either a fish or a pumpkin and hangs it by a thread. But the fish has 3 parameters and the pumpkin has 2 which caused an error. So in a previous exercise we had to make an extra definition called fish-square which uses only 2 parameters to make a fish. Now we have to implement this same squared fish but with a lambda. Any help is greatly appreciated
(define (fish-square wh l) > this is the fish square functio which makes a fish but with 2 times the same parameter so it looks like a square
(vc-append (filled-rectangle 2 l) (fish wh wh))) > the l is the length of the string that attaches the fish to the string at the top
the fish function is just (fish x y) x makes it longer, y makes it taller.
the pumpkin function is just (pumpkin x y) same story
so my question is, how do rewrite the given code , but with lambda as a parameter.
i would upload an image, but my repuation isn't high enough :s
The string procedure as it is already receiving a procedure as a parameter (you don't have to rewrite it!), decoration can be any two-argument function used for decorating. Now when you call it you can pass a named procedure, for example:
(define (decoration r n)
<body>)
(string decoration
5
40)
... Or just as easily, you can pass the same procedure in-line as a lambda, and if I understood correctly, this is what you're supposed to do:
(string (lambda (r n)
<body>)
5
40)
Just replace <body> with the actual body of the decoration you want to use. In othre words: the change you're expected to do is in the way you pass the parameters to the function at invocation time, but you're not expected to change the function itself.
Imagine you have the procedure +. It could be any really. It takes several arguments but you need a different procedure that takes one and adds that to an already constant value 3.
Thus you want to pass + with the extra information that it should add 3.
A full definition of such procedure would be
(define (add3 n)
(+ 3 n))
which is the short form of the full define
(define add3
(lambda (n)
(+ 3 n)))
Now when passing a procedure 3+ you could actually just pass it's definition. These two does the same:
(do-computation add3 data)
(do-computation (lambda (n) (+ 3 n)) data)
When I evaluate the following expression every time I get the value 10.
(((lambda (x) (lambda () (set! x (+ x 10)) x)) 0))
However I just modify by abstracting the above procedure with a name and call foo every time the value increments by 10!!
(define foo ((lambda (x) (lambda () (set! x (+ x 10)) x)) 0))
Can anybody please explain this?
The function you are calling is a counter that returns a number 10 higher every time it's called.
In the first case, every time, you are creating a new function and then immediately calling it once and then discarding the function. So every time, you are calling a new instance of this counter for the first time, so it should return 10.
In the second case, you create the function once and assign it to a variable and call that same function repeatedly. Since you are calling the same function, it should return 10, 20, ...
newacct is correct, but I would like to go into (a lot) more detail, since this is something that just blew my mind pretty recently.
I'm going to use the terms 'environment' and 'scope' pretty loosely and to mean essentially the same thing. Remember that scheme is a lexical scope language.
When scheme evaluates an expression it will look in its current environment for the values of any variables in the expression. If it doesn't find any in the current environment, it will look in the parent environment. If the value is not in the parent environment then it will look in the next level up and so on until it reaches the top (global) level where it will either find the value or throw an "unbound variable" error.
Anytime you call define you associate a symbol with a value on that environments symbol table. So if you call define on the top-level an entry will be added to the global symbol table. If you call define in the body of a procedure, then an entry will be added to the symbol table of that procedure.
A good way to think about calling define on a procedure is that you are creating an entry in the symbol table that consists of the parameters, body, and environment of that procedure. For example the procedure square would have an entry something like this:
(define a 3)
(define (square x)
(* x x))
GLOBAL
=================
a-|-3
|
square-|-{x}
| {(* x x)}
| {GLOBAL} ---> All the things defined on the global table
Then if I were to call (square a) the interpreter would first look in the environment in which square is defined and it would find that a is associated with the value 3. Then x -> 3 within the body of square and the procedure returns 9. Cool, makes sense.
Things get a little screwier when we start defining helper procedures within procedures, but all you really need to remember is that if it can't find anything associated with a symbol in the current environment, it will move up levels of scope until it does. Also, it will always stop on the first 'match'. So if there is a local x it will prefer it over the global x (rather it will use the local x without ever looking for a global one).
Next, remember that define just adds names to the symbol table, but set! is a mutator that actually changes the values with which a symbol is associated.
So (define b "blah") puts an entry in the symbol table. b => "blah". Nothing crazy. set! will change the actual value:
(set! b "foo")
b => "foo"
but set! can't add anything to the table. (set! c "bar") => UNBOUND VARIABLE C.
This is the most important difference: set! acts like any other procedure in that if it doesn't find the variable in the current scope, it will check progressively higher levels until it finds a match (or throws an error), but define always adds a binding to the scope in which it is called.
Alright, so you understand the difference between define and set!. Good. Now on to the question.
The expression (((lambda (x) (lambda () (set! x (+ x 10)) x)) 0)), as newacct pointed out, is going to return the same value each time because you are calling a new procedure each time. However if you name it you can keep track of the environment created by calling the procedure.
(define foo <--- associated name on the symbol table
(lambda (x) <--- scope where x is defined
(lambda () \
(set! x (+ x 10)) |--- body
x)) /
0) <--- initial value of x
So the inner lambda exists inside the environment created by the first one where the symbol x exists at an initial value of 0. Then set! looks for an entry in the symbol table for x and finds one in the next level up. Once it finds the entry it changes it, in this case adding 10 to whatever value it finds there. The really cool part is that since you associated the whole thing to a name in the global symbol table, that environment continues to exist after each call! This is why we can do cool things like implement message passing objects to keep track of and manipulate data!
Also, the let special form was created for this purpose, and may be a more intuitive way to structure this. It would look like this:
(define foo <--- associated name
(let ((x 0)) <--- scope where x is defined & initial x value
(lambda () \
(set! x (+ x 10)) |--- body
x))) /
I'm actually reading the book for fun but it might be considered homework. At any event, I don't feel comfortable with local state variables at all with this language... Take for example this code:
(define flip
(let ((count 0))
(lambda ()
(if (= 0 count)
(begin (set! count 1) count)
(begin (set! count 0) count)))))
why does this code alternate between 1 and 0? count is given the value of 0 every time this function is called! A python equivalent would be:
class Flip:
def __init__(self):
pass
def __call__(self):
count = 0
if count == 0:
count = 1
return count
else:
count = 0
return count
This returns the same thing every time. I'm confused...
I have a little experience with writing compilers for functional languages, so perhaps a short description of how that function is stored/represented in memory is in order. Every function can roughly be thought of as a pair (E,F) where E is the set of free variables, and F is the "code" of the function itself. When you call the function, it takes the values in E and substitutes those in for the variables in F, and then executes the code using those values.
So, where your example is concerned, you have defined the variable "flip" to be the function returned by your let expression. That function is the stuff inside your lambda. Because "count" is defined outside the lambda, it's a free variable, so it's stored in the function's environment. Then, every time you call (flip), the interpreter goes to the code in the lambda, sees that it needs to look up the value of "count" in the environment, does that, changes it, and returns. That's why each time you call it, the value stored in "count" persists.
If you want count to be zero every time you call flip, put the let expression inside the lambda, so it's a bound variable instead of a free variable.
The lambda is a closure. It's a function that references a free variable (count), which, not being locally defined or one of the parameters, is bound to the closest enclosing lexical environment.
The function being called is the lambda, not "flip". Flip is just a name you've given to the lambda that's returned out of the (let ...) expression.
As for the Python, I don't know the language, but it looks like count should be a member of the Flip object, not a variable local to call.
Because your flip function actually returns a function (which is defined inside lambda)
Each time you call the returned function it modifies its environment.
If you think about it the let creates the environment (and initializes count to 0) only once - when the lambda function is returned to you.
In a sense lambda creates a function object for you which uses environment, whose last frame was initialized in let with a single variable count. Each time you call your function it modifies its environment.
If you call flip a second time it returns another function object with different environment. (count initialized to 0) You can then toggle the two functors independently.
If you want to undestand fully how it works you should read about environmantal model.
it's more like
class Flip:
def __init__(self):
self.count = 0
def __call__(self):
if self.count == 0:
self.count = 1
return self.count
else:
self.count = 0
return self.count
Update with more explanation:
The function in Scheme is a closure that "closes" around the free variable count, which is defined in the scope outside it. The way that count is defined in a let with just the function as the body, means that the function is the only thing that can access it -- making count effectively a kind of private mutable state that is attached to the function.
This is the way "objects" are traditionally created in Scheme in SICP -- to have a let define a bunch of variables (the instance variables, initialized to their initial values), and in the body define a bunch of functions which are "methods" that have shared access to the instance variables. That is why it is natural here to use a Python class to represent what is going on, with count being an instance variable.
A more literal translation into Python 3.x would be something like this (note that it is only approximate as Python doesn't have a let (limited-scope local variable declaration) syntax, and Python's lambdas can't be used because they don't take statements):
count = 0
def flip():
nonlocal count
if count == 0:
count = 1
return count
else:
count = 0
return count
# pretend count isn't in scope after this
The problem with the original code is that it has a strong influence of the imperative style. A more idiomatic solution will be:
(define (flip)
(let ((flag #t))
(lambda ()
(set! flag (not flag))
(if flag 1 0))))
To answer the question in you comment ooboo, you want a function that returns a function
(define make-flipper
(lambda ()
(let ((count 0))
(lambda ()
(let ((v count))
(set! count (- 1 count))
v)))))
;; test it
(let ((flip-1 (make-flipper)))
(format #t "~s~%" (flip-1))
(format #t "~s~%" (flip-1))
(format #t "~s~%" (flip-1))
(let ((flip-2 (make-flipper)))
(format #t "~s~%" (flip-2))
(format #t "~s~%" (flip-2))
(format #t "~s~%" (flip-2))))
You can trivially change the set! line so that it becomes a counter, not a flipper (more useful).
What's the point of using the set! assignment operator in scheme? Why not just rebind a variable to a new value using define?
> (define x 100)
> (define (value-of-x) x) ;; value-of-x closes over "x"
> x
100
> (value-of-x)
100
> (set! x (+ x 1))
> x
101
> (value-of-x)
101
> (define x (+ x 1))
> x
102
> (value-of-x)
102
>
Though both define and set! will redefine a value when in the same scope, they do two different things when the scope is different. Here's an example:
(define x 3)
(define (foo)
(define x 4)
x)
(define (bar)
(set! x 4)
x)
(foo) ; returns 4
x ; still 3
(bar) ; returns 4
x ; is now 4
As you can see, when we create a new lexical scope (such as when we define a function), any names defined within that scope mask the names that appear in the enclosing scope. This means that when we defined x to 4 in foo, we really created a new value for x that shadowed the old value. In bar, since foo does not exist in that scope, set! looks to the enclosing scope to find, and change, the value of x.
Also, as other people have said, you're only supposed to define a name once in a scope. Some implementations will let you get away with multiple defines, and some won't. Also, you're only supposed to use set! on a variable that's already been defined. Again, how strictly this rule is enforced depends on the implementation.
It is not usually permitted to define a variable more than once. Most REPLs allow it for convenience when you're trying things out, but if you try to do that in a Scheme program it will give you an error.
For example, in mzscheme, the program
#lang scheme
(define x 1)
(define x 2)
gives the error
test.ss:3:8: module: duplicate definition for identifier at: x in: (define-values (x) 2)
In addition, define has a different meaning when used inside of other contexts. The program
#lang scheme
(define x 1)
x
(let ()
(define x 2)
x)
x
has the output
1
2
1
This is because defines inside of certain constructs are actually treated as letrecs.
When you use lexical bindings you do not define them:
(let ((x 1))
(set! x (+ x 1))
x)
When you use define you create a new variable with the new value, while the old variable still exists with the old value; it is just hidden by the new one. On the command line you don't see the difference to set!, but define won't be usable for e.g. a loop counter in an imperative program.