Re: Change in semantics for some control flow operations

Is there any difference between #1 and #2 from a user's point of view or is this strictly a question of implementation?

i.e. it looks like #1 basically clears the locals on every iteration, while #2 keeps them around in case the user declared a local in the loop he can use it on the next iteration.  Is that right?

What will the syntax be for setting slots in the outer scope from within the loop?

Kevin

P.S. Yahoo's giving me a "Your email was not delivered due to a suspected guidelines violation." so I'm posting using the web form.  Maybe it's just me.  I'm not a spammer!  Honest! :-)

--- In [email protected], Jeremy Tregunna <jeremy.tregunna@...> wrote:
>
> So... no input? Should I assume that this means there's no objection to this, or either implementation strategy?
> 
> Regards,
> 
> Jeremy Tregunna
> 
> On 2011-12-08, at 8:43 AM, Jeremy Tregunna wrote:
> 
> > 
> > I want to propose a change in direction for the standard library foreach(), select(), and friends methods. I'll supply code, don't worry about that.
> > 
> > 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
> > 
> > 
> > 
> > 
> >
>