Named lambdas (was Re: Serialization stability and naming (and syntax))

[Kevin Bourrillion]

On Fri, Oct 12, 2012 at 8:36 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

In both cases we would still have to deal with ambiguity, which is worse in
> the method param case.
>

Well, nothing's perfect.  This still seems like a reasonable approach and
seems to cost the user nothing.



>
> Sent from my iPhone
>
> On Oct 12, 2012, at 3:54 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>
> We can use the name of the parameter of the method. The parameter name is
> stored in the bytecode by java 8 and available in local variable table (if
> the symbols are not striped) if the bytecode version is < 8
>
> Rémi
>
> Sent from my Phone
>
> ----- Reply message -----
> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Kevin Bourrillion" <kevinb at google.com>
> Cc: <lambda-spec-experts at openjdk.java.net>
> Subject: Named lambdas (was Re: Serialization stability and naming (and
> syntax))
> Date: Fri, Oct 12, 2012 16:33
>
>
> I assume you're talking about lambda names now, and not recursion?
>
> If so, this works for lambdas assigned to locals but not to lambdas passed
> to methods.
>
> On Oct 12, 2012, at 3:06 PM, Kevin Bourrillion wrote:
>
> Huh. Can it be that simple? This works for me if no one else sees a
> problem with it!
>
>
> On Tue, Oct 9, 2012 at 10:30 AM, Dan Smith <daniel.smith at oracle.com>wrote:
>
>> The approach we settled on for names for recursive lambdas was to use the
>> targeted variable name:
>>
>> IntOp fact = x -> {
>>   if (x == 0) return 1;
>>   else return x*fact.apply(x-1);
>> };
>>
>> That also seems like a useful, unobtrusive way to give a lambda a name
>> for debugging.  If somebody cares about readable names for debugging,
>> they'll probably also care about readable names in code, and the way you
>> name something in code is assign it to a variable.
>>
>> Of course there will be cases where we'd need the name to be "fact$2" or
>> something, but for a best-effort problem like debugging hints, that seems
>> good enough.
>>
>> —Dan
>>
>> On Oct 9, 2012, at 9:40 AM, Kevin Bourrillion <kevinb at google.com> wrote:
>>
>> Okay, so the benefits of user-provided names seem to be
>>
>> - More readable toString and stack traces than the auto-provided name
>> (lambda#8 or whatever)
>> - A very small (as noted by Brian) potential to make serialization usable
>> across code changes in a few more situations
>> - It should apparently help hot-swapping to be usable in a few more
>> situations
>>
>> Anything else?
>>
>> If we come up with some syntax for users to name individual lambda
>> expressions, do we think these benefits are great enough that enough users
>> will name their lambdas enough of the time to get real benefit?  I'm
>> unsure.  Even though lambdas are way more concise than classes, this
>> supreme terseness of lambda expressions is sort of intoxicating and I
>> wonder if most users will get drunk on that and not want any extra
>> characters that weren't strictly required.
>>
>> Likewise, to the extent that any of the advantages can also be realized
>> by switching to a method reference, do we think enough users will actually
>> be willing to make that switch?
>>
>>
>> On Sun, Oct 7, 2012 at 11:44 AM, Andrey Breslav <
>> andrey.breslav at jetbrains.com> wrote:
>>
>>> I would like to point out one thing that somehow keeps escaping our
>>> discussions of this matter.
>>>
>>> Although for some people serialization is the biggest concern here, for
>>> a lot more people a much bigger concern is hot-swapping, where name
>>> stability is very important as well.
>>>
>>> In my mind, this requires us to reconsider the arguments for having/not
>>> having stable names/signatures where we could have that.
>>>
>>> --
>>> Andrey Breslav
>>> http://jetbrains.com
>>> Develop with pleasure!
>>>
>>>
>>>
>>
>>
>> --
>> Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
>>
>>
>>
>
>
> --
> Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
>
>
>


-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121012/c822fd87/attachment-0001.html