Checked exceptions within Block<T>

[Remi Forax]

On 01/16/2013 10:32 PM, Neal Gafter wrote:
> On Wed, Jan 16, 2013 at 10:24 AM, Remi Forax <forax at univ-mlv.fr 
> <mailto:forax at univ-mlv.fr>> wrote:
>
>     The current lambda spec doesn't allow to capture variable, only
>     value can be captured.
>
>
> The current spec allows you to use the name of a variable inside the 
> lambda after the scope in which the variable was declared has exited. 
>  The meaning is that it gives the value last (and only, in the current 
> spec) assigned to that variable.  You can't "capture a value" because 
> a value does not have a name.  Allowing capture of mutable variables 
> simply removes the parenthetical restriction in my description.

you can capture the value of the variable when you do the lambda conversion.

>
>         There is no reason for such lambdas to be "biased to the
>         current thread".
>
>
>     There is a good reason, avoid to have to declare volatile local
>     variable.
>     And if you can transfer ownership  I don't see the problem.
>
>
> For the same reason, you should be able to declare instances of 
> classes "biased to the current thread" so that you can "avoid to have 
> to declare volatile fields".  Unless you're considering that for 
> classes, I don't see why you'd consider that for lambdas.

The current abstraction is fields are spaces in shared memory (the heap) 
and local variable are thread local spaces (the stack). That why I think 
that stack variable captured by a lambda should be thread local (that 
may be promoted to shared space but explicitly).

Rémi