this should not refer to the lambda

[Neal Gafter]

On Sun, Feb 21, 2010 at 3:25 PM, Alex Blewitt <alex.blewitt at gmail.com> wrote:
>> I don't know what you mean by "break the language model".
>
> I don't know any construct in Java - or for that matter, other languages - where the
> RHS of an assignment expression can refer to the lHS of the assignment expression,
> as  you proposed in http://mail.openjdk.java.net/pipermail/lambda-dev/2010-February/000833.html

I didn't propose anything for the assignment expression.  I proposed
something about the initialization in a variable declaration.  For
examples see Haskell, or lisp's letrec, to pick two obvious
candidates.  Just because you don't know about it doesn't mean it's a
bad idea.

>> The task at hand is to define the language.  The observation that this is
>> different than existing constructs doesn't necessarily make it bad.
>
> That's true, but I wasn't saying that it was different ergo it was bad. I was saying that we
> should not allow any expression to be defined in terms of the LHS that it is being assigned to.
> It would involve fairly hairy changes to the 'Simple assignment operator' section in the JLS.

No, it has nothing to do with the simple assignment operator.  It
would only be a special case for variable initialization.

> As I understand it (and I may be wrong; please correct me if so), the 'transparency' argument requires:

Transparency is a litmus test.  It suggests, not requires.

> If we end up in a situation where the transparency opportunities have already been
> blown by virtue of the break/continue/return/mutable access, then it seems that
> blowing transparency via 'this' does not add additional disadvantages to the proposal as it stands.

That's not the case.  The advantages of transparency accrue (or the
disadvantages accrue) for each element that satisfies it (or fails to
satisfy it).

Cheers,
Neal