Just as a quick clarification: if, in the scenario below, thread T2
uses parameterize to change P1 and P2 before invoking K1 (instead of
mutation), then the values seen by the whatever's left to be done in
the continuation K1 would be 0 and 1, not 2 and 2, right?

In code, the first program is what Kent describes below in mzscheme
notation and the second is the change I'm asking about (and we see
what he predicts for the first case):

;; program 1, like Kent's below

(define p1 (make-parameter 0))
(define p2 (make-parameter 0))
(define k #f)
(define t
 (thread
  (λ ()
    (parameterize ([p1 1])
      (write ((call/cc (λ (_k) (set! k _k) void))))
      (newline)))))

(thread-wait t)  ;; wait for t to complete
(thread
(λ ()
  (p1 2)
  (p2 2)
  (k (λ () (list (p1) (p2))))))

;; program 2, the one I'm asking about:
(define p1 (make-parameter 0))
(define p2 (make-parameter 0))
(define k #f)
(define t
 (thread
  (λ ()
    (parameterize ([p1 1])
      (write ((call/cc (λ (_k) (set! k _k) void))))
      (newline)))))

(thread-wait t)
(thread
(λ ()
  (parameterize ([p1 2]
                 [p2 2])
    (k (λ () (list (p1) (p2)))))))

Robby

On 2/21/07, R. Kent Dybvig <[EMAIL PROTECTED]> wrote:
> So the swapping compensates for the effect of side effects, and gets a
> notion similar to "call/cc captures the contents of the storage
> associated with the parameters."  Except it seems to break down in the
> presence of threads, as Kent explained here:
>
> http://lists.r6rs.org/pipermail/r6rs-discuss/2007-February/001536.html

There's no claim of any break down in that note, just a clarification:
call/cc effectively captures only the values of the parameters that are
parameterized in the continuation, rather than the values of all
parameters.  Here's an example illustrating the difference.

Let's assume that:

  parameter P1 is defined to be 0
  parameter P2 is defined to be 0
  thread T1 parameterizes P1 to 1 then grabs a continuation K1
  thread T2 assigns P1 to 2 and P2 to 2, then invokes K1

If call/cc were to capture the current contents of *all* parameter
locations:

  code run in K1 by T2 would see P1 = 1 and P2 = 0

Since, however, call/cc actually captures only the current contents of the
parameters parameterized in the continuation, only the value of P1 is
captured, and

  code run in K1 by T2 actually sees P1 = 1 and P2 = 2

This allows different threads to assign different default values to its
parameters, with only those that are parameterized by a continuation
overriding those defaults.  For example, I might want each thread to
redirect its diagnostic output to a different port by setting the
current-output-port parameter while letting a continuation determine the
values of other parameters via parameterize.

Kent

_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss

_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss

Reply via email to