this should not refer to the lambda

[Neal Gafter]

On Sun, Feb 21, 2010 at 2:18 PM, Alex Blewitt <alex.blewitt at gmail.com> wrote:
> Whether it's easy to implement is somewhat orthogonal to whether a language
> should be able to define a variable assignment with a LHS that refers to
> itself in the RHS. So, as noted, it appears to come to:
> * 'this' refers to the lambda, or
> * 'this' refers to enclosing object, and
>   * recursive lambdas are disallowed, or
>   * we break the language model such that special-cases of LHS assignments
> can refer to the LHS in the RHS

I don't know what you mean by "break the language model".  The task at
hand is to define the language.  The observation that this is
different than existing constructs doesn't necessarily make it bad.
You correctly frame the question as to whether the language "should"
allow this.  We have technical reasons in its favor, and philosophical
reasons against.

> If the point boils down to 'it should be possible to surround any code with
> a lambda block and execution', [and the original code] are the same thing
> and can be done with no other changes, then the fact is
> that it's already impossible to do this.

The fact that things are bad doesn't mean we should make them worse.
Project lambda may not provide complete transparency, but that doesn't
undermine the value of transparency in the construct where project
lambda has a choice of making an aspect transparent or not.  Your
example of nonfinal variable capture failing to be transparent is why
the issue of access to nonfinal variables continues to be an issue for
the spec.

Cheers,
Neal