Current State of Closures

[Josh Stone]

I assume this is why you haven't addressed Reinier's comments in the
"Revisiting primitives in generics" thread, among others, but I do believe
they warrant a response.

Josh

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