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?

>- 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. 
      
>- 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"?


Thanks very much for your help.
  -Patrick


On Sun, Nov 3, 2013 at 6:03 AM, Marc Feeley <feeley@iro.umontreal.ca> wrote:

On Nov 3, 2013, at 12:27 AM, Patrick Li <patrickli.2001@gmail.com> wrote:

> Hello!
>
> I am interested in the design choices surrounding SRFI-39: the
> make-parameter function and parameterize special form. There are
> specifically 2 issues that I don't understand.
>
> 1) The parameter is currently a function that yields the value its
> holding when it is called. What is the purpose of forcing the user to
> "dereference" the parameter in this way? This is constrast to
> implementing dynamic variables using a mutable global variable, and
> having parameterize directly mutate the global variable within a
> dynamic-wind context.

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)

- it doesn't handle mutation (you would have to introduce cells for that, and dereference these cells when accessing the parameter)

- it doesn't work in a multithreaded environment (the content of the parameters will be clobbered by the different threads operating on those parameters)

> 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

Marc