this should not refer to the lambda

[Alex Blewitt]

On 21 Feb 2010, at 22:57, Neal Gafter wrote:

> 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".

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

#int(int) fac = #(int x)(x <= 1 ? 1 : x * fac.(x-1));

Putting aside the types/contents of the expression, we basically have:

... fac = ... fac ...

I have a philosophical reason against allowing that construct. So, if we disallow this, we disallow recursive lambdas (assuming this=enclosing object, instead of enclosing lambda). Hence the point 'recursive lambdas are disallowed, or ...'  above.

> 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.

http://java.sun.com/docs/books/jls/second_edition/html/expressions.doc.html#5295

For example, would you be able to assign a value in a chain?

... foo = ... fac = #() { ... fac }
... fac = ... foo = #() { ... fac }

Arguably these are unlikely to come up, but the language should be able to defend such uses under the JLS, regardless of implementation chosen.

>> 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.

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

* Treating 'this' as the enclosing object, not the enclosing lambda
* Having 'return' exit the enclosing method, and not the lambda
* Having 'break/continue' operate in the enclosing method scope, and not the lambda
* Allowing mutable access to anything in scope, not just (effectively) final variables

My understanding of the latest spec is that all bar the first have been decided against as it stands in the current draft.

> 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.


Yes, and this is why we are still discussing; though as someone wiser than myself has already noted, we are just providing input for those at Oracle who will make the ultimate call. What is certain is that at least some people will be disappointed :-)

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. 

On the other hand, if mutable access and control flow (including returns) are permitted as per the transparency argument, then I would concur that for consistency's sake, it would make sense for 'this' to act transparently as well.

I suspect others would agree that there's limited benefit in only providing partial transparency; if that's the case, then none and some are equivalent. (Others may disagree, though.)

Alex