return-from-lambda viewed as dangerous, good alternatives
Rémi Forax
forax at univ-mlv.fr
Thu Jan 7 02:29:55 PST 2010
Le 07/01/2010 10:16, John Rose a écrit :
> On Dec 28, 2009, at 8:25 AM, Neal Gafter wrote:
>
>
>> To: Peter Levart<peter.levart at gmail.com>
>> Cc: lambda-dev at openjdk.java.net
>> Subject: Re: transparent lambda
>>
>> I'm moving this conversation to the closures-dev mailing list.
>>
> I note that the closures-dev group is dealing with the details of what fully transparent lambdas would look like, and in particular how to avoid overloading "return". I've followed up there with some detailed observations:
> http://mail.openjdk.java.net/pipermail/closures-dev/2010-January/000534.html (etc.)
>
> For the purposes of this list (lambda-dev), I want to make a clear argument against overloading the "return" keyword to denote a lambda result value, in addition to its denotations in current Java. I also want to suggest a range of alternatives.
>
[...]
I am with John about that.
In my opinion, if lambda are anonymous functions, return should return
the lambda result value
and lambda will never be transparent lambda.
Or if we want in the future support transparent lambda, return/break and
continue must have
the same meaning as in a function. In that case, lambda aren't anonymous
function but
anonymous expression/block of code and we have to have a new syntax for
exiting with
a value from a lamda block.
About the proposed syntax, I don't like 'let expression' because for
consistency
they should be used everywhere like in Scala or Groovy, this is not the
case in Java.
I prefer a keyword, any new keyword but not 'yield' which is reverved
for coroutine. I propose 'giveup' :)
+ a way to label lambda to distinguish lambda in case of lambda in
lambda (like we distinguish
loop with labeled break or continue).
Proposed syntax:
public int f() {
return lambda() {
giveup 4;
}.invoke();
}
public int f() {
return lambda foo() { // named lambda
lambda() {
giveup foo: 4;
}.invoke();
}.invoke();
}
Rémi
More information about the lambda-dev
mailing list