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