Current State of Closures

[Reinier Zwitserloot]

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
>
>