Re: Change in semantics for some control flow operations

On Thu, Dec 08, 2011 at 08:43:12AM -0600, Jeremy Tregunna wrote:
> 
>    Right now, how we go about doing things is once we're iterating, we set
>    values in the calling context directly. This has obvious problems worse
>    than shadowing, i.e., overwriting values we want and persisting after
>    the foreach() has finished. Now at present, anyone hit by this problem
>    will have renamed their identifiers when they got bad results, but this
>    is rather confusing. Additionally, why should we leak these values?
> 
>    I'm proposing one of two solutions I think are a better fit:
> 
>    1. Set up a block with the argument name(s) we want to set, the body we
>    want to evaluate, and the proper scope to capture (the sender). Call
>    that inside our main loop.
> 
>    2. Create a separate isolated context outside the loop, set our
>    value(s) in it inside the loop, ask our body to doInContext with that
>    context and the sender. This has a slight advantage performance wise in
>    that we only create one context, as opposed to creating N locals with
>    the block worst case (or recycling N locals depending on our
>    environment).
> 
>    Now, this does have the negative use in that it breaks operational
>    semantics of these methods at present if a user depends on this
>    behaviour, but I'm ok with that; I'd consider that behaviour broken
>    anyway.
> 
>    I think this should be done to all the standard library objects that
>    support these types of constructs. Take some of the surprise out of
>    using them.
>    Regards,
>    Jeremy Tregunna

So I saw the discussion, but I didn't hear a conclusion. Did you win
support for this change?

  Eric