this should not refer to the lambda

Alex Blewitt alex.blewitt at gmail.com
Sun Feb 21 14:18:01 PST 2010


On 21 Feb 2010, at 21:56, Neal Gafter wrote:

> On Sun, Feb 21, 2010 at 12:29 PM, Alex Blewitt <alex.blewitt at gmail.com> wrote:
>> I don't recall seing a suggestion of how to implement a recursive
>> lambda (which is 'rare' but not 'extinct') without breaking the
>> illegal forward reference issue that I mentioned previously. I could
>> have missed something; can you forward me the link of where that is
>> done?
> 
> Sure: http://mail.openjdk.java.net/pipermail/lambda-dev/2010-January/000432.html
> 
> Just to be clear, the one minor adjustment to the definite assignment
> rules that is needed if you want to allow, for example
> 
> #int(int) fac = #(int x)(x <= 1 ? 1 : x * fac.(x-1));

This is the example of the breaking the forward reference which I cited in my post you originally replied to. Specifically:

http://mail.openjdk.java.net/pipermail/lambda-dev/2010-February/000823.html

It seems this doesn't prevent anything and doesn't require self-refs  
to be designed as:

Object me = #() { me }

There is no other construct in Jaca [sic] where you can do:

Object foo = ... foo ...

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

>>> The technical arguments for
>>> transparency of semantics for lambdas have been made in many contexts over
>>> the years.  A good place to start is with Steele's "Lambda the Ultimate..."
>>> series of papers.
>> And yet, they've not been made/summarised here; ...
> 
> Some of them have, actually, but rather than continuing to predigest
> the information for you, perhaps you would care to take a stab at it.

If the point boils down to 'it should be possible to surround any code with a lambda block and execution', i.e. that:

--- 8< ---
foo;

and

#() {
  foo;
}.(); // define, then execute, the lambda
--- 8< ---

are the same thing and can be done with no other changes, then the fact is that it's already impossible to do this.

--- 8< ---
int sum = 0;

for(int i=0;i<10;i++ )
  sum += i

System.out.println(sum);

->

int sum = 0;

#() {
  for(int i=0;i<10;i++ )
    sum += i
}.(); // define, then execute, the lambda

System.out.println(sum);
--- 8< ---

This will fail to compile for the (obvious) reason that 'sum' is not final. Therefore, there are some expressions such that it is not possible to surround with a lambda block/execute statement; which is my understanding of the 'transparency' argument. 

I may, of course, have misunderstood the details of 'transparency' here - but if the argument lies that 'this' refers to other references, and as such, an 'accidental' capture of something with a lambda (as in here) would fall into the category of problematic statements. 

Please let me know if I have misunderstood/misrepresented the transparency argument here.

Alex


More information about the lambda-dev mailing list