Current State of Closures

[Nathan Bryant]

Regarding implementing primitives in generics as basically syntactic
sugar for the boxed types:

This doesn't solve much of anything that has not been already addressed
by autoboxing.

More, the motivating use case for primitives-in-generics is to avoid the
runtime overhead of autoboxing, and the rationale for Reinier's proposal
is that it's OK to rely on VM optimizations for this. But the tests I've
performed on JRockit, JDK6 and JDK7 indicate pretty clearly that
autoboxing-elimination does not work as well as primitive types (simple
operations can still be an order of magnitude slower, even in the
sequential case which is much easier for the VM to inline.) Simply put,
I can't get the optimization to work at all, for some pretty simple
cases.

-----Original Message-----
From: lambda-dev-bounces at openjdk.java.net
[mailto:lambda-dev-bounces at openjdk.java.net] On Behalf Of Josh Stone
Sent: Wednesday, July 28, 2010 6:45 PM
To: lambda-dev at openjdk.java.net
Subject: Re: Current State of Closures

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