[gambit-list] Two basic questions regarding the use of make-parameter and parameterize.

Marc Feeley feeley at iro.umontreal.ca
Mon Nov 4 10:46:41 EST 2013

On Nov 3, 2013, at 2:18 PM, Patrick Li <patrickli.2001 at gmail.com> wrote:

> Thank you very much for your reply Marc!
> >This implementation technique has problems:
> >
> >- the cost of call/cc will be proportional to the number of parameters
> >  (because at the time of creating a continuation you have to take a
> >  snapshot of all those parameters, and when the continuation is
> >  invoked you have to copy the snapshot back to the parameters)
> The cost of call/cc would be proportional to the number of
> parameterize (and hence dynamic-wind) calls you would be currently
> nested in right? Other parts of the program, that are not as deeply
> nested in parameterize, would not be affected. Is my understanding correct?

When a continuation is invoked, some dynamic bindings must first be undone (unwinding phase) and then some dynamic bindings myst be redone (winding phase).  So it is proportional to the sum of the nesting depths (or more precisely, the nesting depth from the closest common branches of the dynamic environment).

> >- it doesn't handle mutation (you would have to introduce cells for
> >  that, and dereference these cells when accessing the parameter)
> I don't quite understand this aspect. 
> I expect:
>    (parameterize [(a 3)]
>       ... body ...)   
> to be roughly equivalent to:
>    (let [(old-a a)]
>       (dynamic-wind
>          (lambda () (set! a 3))
>          (lambda () ... body ...)
>          (lambda () (set! a old-a))))
> So I would expect to be able to use (set! a 10) from within the body
> just like normal. 

This would work in a single threaded Scheme implementation, but not in a multithreaded implementation.  For your information this is called the "shallow binding" implementation, and it was (is) used in some implementations of Lisp (google it).

> >- it doesn't work in a multithreaded environment (the content of the
> >  parameters will be clobbered by the different threads operating on
> >  those parameters)
> Yes. Threading & Dynamic bindings together seem subtle. 
> >> 2) Is there a way to get a closure to close over the dynamic
> >> environment? The use case is that I want to use dynamic variables
> >> *purely* to avoid having to pass commonly used arguments
> >> explicitly. Thus I am using the dynamic variable as an "implicitly"
> >> passed argument. And in such a case, I would like closures to refer
> >> to the value of the dynamic variable at the time of closure
> >> creation.
> >
> >Closures capture the lexical variables.  Parameter objects can't be
> >automatically captured by closures because that would mean that a
> >calling function can't use parameter objects to pass implicit
> >parameters to the called function.  So if you want to capture the
> >value of some parameter objects you will have to do it manually,
> >i.e. something like:
> >
> >(define p (make-parameter 42))
> >
> >(define (make-adder) ;; creates a function which adds the value of
> >  parameter p (let ((captured-p (p))) (lambda (x) (parameterize ((p
> >  captured-p)) (+ x (p))))))
> >
> >(define a (make-adder))
> >
> >(p 1000) ;; change value of parameter p
> >
> >(pp (a 10)) => 52
> >
> >(p) => 1000
> I understand the example that you gave on how to manually capture the
> parameter object. Could you clarify what you mean by "a
> calling function can't use parameter objects to pass implicit
> parameters to the called function"?

Lets assume that parameter objects are automatically captured by closures.  That means that when a closure is called, the dynamic bindings that were in effect at the moment that the closure was created will be reinstated at the beginning of the execution of the body of the closure.  Now examine the following code and ponder what is returned by the last 3 expressions:

(define p (make-parameter 111))

(define (make-adder x)
  (parameterize ((p x))

(define (f)
  (lambda (y) (+ y (p))))

(define g (make-adder 222))
(define h (f))

(g 0) => ?
(h 0) => ?
(parameterize ((p 333)) (h 0)) => ?

The closure in g remembers that p was bound to 222, and the closure in h remembers that p was bound to 111.  So in the call (g 0) the result will be 222 (i.e. 0+222), and in the first call (h 0) the result will be 111 (i.e. 0+111).  What happens in the last expression?  The parameter p is dynamically bound to 333, and then h is called. Because h remembers that p was bound to 111, it reinstates this binding for the evaluation of its body, (+ y (p)), so the result is 111 (i.e. 0+111).  So that's what I meant when I said "a calling function can't use parameter objects to pass implicit parameters to the called function".  The idiom (parameterize ((p ...)) (fn ...)) no longer works for passing the implicit parameter p to fn.

Note that when parameter objects are automatically captured by closures, parameter objects behave like lexical variables!  Consequently they would be completely redundant in the language.


More information about the Gambit-list mailing list