> > be scoping conflicts with Procs passed to Procs is a 
> fallacy, in that they 
> > would be subject to the same scoping rules that other 
> objects are subject to.
> 
> Currently the ``yielding block'' is frozen at (method or 
> proc) definition time
> and it is impossible to change it afterwards (this is not 
> exactly a scoping issue
> in my book) - if one longs for more flexibility one can 
> explicitly pass Procs as 
> parameters around and use Proc::call instead of yield - i.e. 
> we already have 
> Procs passed to Procs with the scoping rules you describe.

Sorry for the scoping red herring - I was trying to explain why procs have a
'yielding block' frozen in at definition time, but I think I merely muddied
the water :(

Thanks to Christoph for elaborating & explaining what I really meant.

-- George