At Sun, 25 Jul 2021 10:35:00 -0700 (PDT), Greg Rosenblatt wrote: > I was surprised that subsequent re-entries can observe modifications from > the earlier ones, since my mental model of dynamic parameters was that > their values were retrieved from a fresh dynamic calling context, whose > frames are copied each time the delimited continuation is invoked. > [...] > I'm also interested in the reasons behind the current design. Is there a > downside to storing parameter bindings directly on the stack, rather than > in a thread cell pointed to by the stack?
I think I see what you mean here, but I also think that idea would run into trouble. A (delimited) continuation is invoked every time you return a value to a continuation, whether or not that continuation was captured by `call/cc`. Internally, in fact, the current continuation frequently gets reified and invoked through returns. I think it would create a bad interaction among features if a distinction were made between explicit (applying a captured continuation) and implicit (returning a value) continuation invocations. > I'd like to be able to resume that continuation in the same context > multiple times without observing modifications caused by other > resumptions. [...] But it looks like dynamic parameters actually rely > on a shared mutable cell, in this case a thread cell. Yes, parameters are based on a mapping parameter * thread * paramterizization -> box When you set or look up a parameter value, the thread part comes from `current-thread`, and the parameterization part comes from a continuation mark. So, that's why capture and restore within a thread sees the same box, but capture and restore of a continuation in a different thread gets a different box. I think you want to introduce a notion of "resume" that replaces the thread part of the mapping, plus a replacement notion of parameterization. That is, each time you resume, the applied continuation should extend one that maps an internal mark to the current resume. A replacement for `parameterize` would also install a mark (with a different key) to identify a "parameterization", while also mapping the parameter * parameterization * resume to a fresh box. When you look up a parameter value or mutate a parameter, the current mark for the resume and the current mark for the parameterization would let you find the right box. It may be best to have a "parameterization" specific to each "parameter" (i.e., a separate mark for each parameter), instead of aggregating them in the way `parameterize` does. In the case of threads and parameters, aggregation makes it easier to create a new thread that inherits the parameterization of the creating thread. But if you don't need that, aggregation also works less well with delimited continuation capture, because `parameterize` captures all parameter values and not just the ones that are set in the `parameterize` form. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/20210730090404.311%40sirmail.smtps.cs.utah.edu.
