Current State of Closures

[Fredrik Ohrstrom]

2010/7/29 Nathan Bryant <nathan.bryant at linkshare.com>:
>
> 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.

You are quite right. The release cycles are long, so the improvements
I made to autboxing last fall are going to be part of the next release.
Please try again.

//Fredrik

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