Current State of Closures
Talden
talden at gmail.com
Tue Jul 27 03:34:15 PDT 2010
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
More information about the lambda-dev
mailing list