[plt-scheme] composable continuations and dynamic state

At Thu, 04 Jun 2009 12:29:03 -0400, Ryan Culpepper wrote:
> Taylor R Campbell wrote:
> > [By the way, thanks for cc'ing me -- I forgot to mention in my first
> > message that I am not subscribed to the list.]
> > 
> >    Date: Thu, 04 Jun 2009 02:04:43 -0400
> >    From: Ryan Culpepper <ryanc at ccs.neu.edu>
> > 
> >    The thread cell indirection is, as you surmised, totally irrelevant to 
> >    the results. You're seeing the effects of another indirection, the 
> >    "parameterization". Parameter-value associations are not stored 
> >    individually in the continuation. Instead, the continuation contains 
> >    "parameterizations", or mappings of all parameters to their current 
> >    values (really, to their currently associated thread-cells). 
> >    Consequently, when you separate a continuation into parts, you do *not* 
> >    separate the parameter updates belonging to those parts.
> > 
> > OK, thanks: now I understand the mechanism yielding the output shown.
> > My next question is about the rationale:  Why are DYNAMIC-WIND state
> > points only partially preserved, whereas parametrizations are fully
> > preserved?
> 
> I suspect the behavior comes from the early days when parameters were 
> first added, when it seemed like first-class parameterizations were a 
> useful feature: capture a parameterization over here, ship it somewhere 
> else and reinstate it there. I thought that they were no longer used, 
> but a search for 'parameterization' in the source tree does turn up a 
> number of hits.

Roughly, yes. We had them in a bad form (shared mutation among
threads), threw them out, and then brought them back in a better form
to solve some context-switching problems for DrScheme. But, with the
advent of delimited continuations, the revised form still creates
trouble.

> It also seems like storing parameterizations might make parameter 
> lookups faster, but I haven't tried to test that conjecture. Perhaps 
> Matthew has?

The last time I looked at this problem, I didn't find the right data
structure to get both parameterization values and acceptable
algorithmic complexity for parameter operations. It needs another look;
the solution may involve throwing out parameterizations (again) and
finding a different solution for the problem switching back and forth
between different contexts (e.g., DrScheme versus the program that it
runs).

> In fact, I got bitten by the parameter issue the last time I played with 
> delimited continuations. If you're using delimited continuations, I'd 
> recommend avoiding parameters and using continuation marks or a light 
> abstraction thereof (like the "dynamics" I sent in my previous message). 
> More precisely, avoid using 'parameterize' in code that may be appear in 
> a composable continuation.

Agreed.