Current State of Closures

[Brian Goetz]

Yes, you're seeing denial in action.

On Jul 28, 2010, at 2:37 PM, Reinier Zwitserloot wrote:

> I keep seeing #returnType(paramTypes) mentioned, but doesn't SotL eliminate
> those entirely?
> 
> --Reinier Zwitserloot
> 
> 
> 
> On Tue, Jul 27, 2010 at 12:34 PM, Talden <talden at gmail.com> wrote:
> 
>> On Tue, Jul 27, 2010 at 8:44 PM, Peter Levart <peter.levart at marand.si>
>> wrote:
>>> I didn't see that mentioned in the drafts. But with current prototype and
>> it's syntax using target typing with inferal of lambda's argument types, the
>> alternative is not so much longer and is more general, since you have the
>> control over argument positions:
>>> 
>>> public class TestClosures
>>> {
>>> public static #Integer(Integer) partial(final #Integer(Integer, Integer)
>> func, final int arg1)
>>> {
>>>   return #(arg2){ func.(arg1, arg2) };
>>> }
>>> 
>>> public static void main(String[] args)
>>> {
>>>   #Integer(Integer,Integer) pow = #(x, y){x * y};
>>>   #Integer(Integer) part = partial(pow, 2);
>>>   System.out.println(part.(2));
>>> }
>>> }
>> 
>> I assume it would be possible to provide a nearly equivalent
>> genericised form (only nearly because you can't generically involve
>> the primitive).
>> 
>> Something like this?
>> 
>> public static <X, Y, Z> #Z(Y) curryFirst(final #Z(X, Y) func, final X arg1)
>> {
>>  return #(arg2) { func.(arg1, arg2) };
>> }
>> 
>> Such that you could say
>> 
>> #Integer(Integer, Integer) adder = #(x, y) { x + y };
>> #Integer(Integer) plus10 = curryFirst(adder, 10);
>> 
>> Do I have that right?
>> 
>> Are these lambda type declarations still valid under the current state
>> of the lambda or are SAMs required instead now?  I thought I saw
>> something about these declarations not being supported and the removal
>> of the "block.(...)" notation as well.  A shame if that's the case.
>> 
>> --
>> Aaron Scott-Boddendijk
>> 
>> 
>