Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Java (http://www.velocityreviews.com/forums/f30-java.html)
-   -   a convert to lambda-ism (http://www.velocityreviews.com/forums/t738031-a-convert-to-lambda-ism.html)

Lew 11-15-2010 02:22 AM

a convert to lambda-ism
 
I've been perusing
<http://cr.openjdk.java.net/~mr/lambda/straw-man/>

For the first time in the closures debates, I'm a fan of lambda expressions in
Java now.

Not that I've ever been against them, really, just haven't missed them before.
At this point the state of Java discourse around closures has matured to
where I see clear value in the proposal. It appears that the straw-man
proposal integrates, or at least aims to integrate the best of all the major
proposals.

From the link, 2009/12/10:
"This proposal builds upon the past work of Gilad Bracha, Neal Gafter, James
Gosling, and Peter von der Ahé on BGGA; of Bob Lee, Doug Lea, and Josh Bloch
on CICE; and of Stephen Colebourne and Stefan Shulz on FCM. There is little
here that is new beyond the synthesis of selected elements of those, and
related, proposals."

I note that this positive progress is happening under Oracle's aegis, and is
projected for Java 8. Yes, that's right, they're planning an 8.

--
Lew

markspace 11-15-2010 04:15 AM

Re: a convert to lambda-ism
 
On 11/14/2010 6:22 PM, Lew wrote:
> I've been perusing
> <http://cr.openjdk.java.net/~mr/lambda/straw-man/>



I've been following, off and on, the development on their mailing list:

<http://mail.openjdk.java.net/pipermail/lambda-dev/>

I believe the latest draft/update is here:

<http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-3.html>

The switch from Java 7 to Java 8 happened a while back. Basically, all
the features planned for Java 7 would have delayed it by at least a
couple of years. So they broke Java 7 into two parts: the easy bits and
the hard bits. Easy bits are going out ASAP in Java 7, the harder stuff
will be delayed and then go out in Java 8.

Weird, but I do think getting something out for Java 7 ASAP was the
right choice.



Kevin McMurtrie 11-15-2010 04:35 AM

Re: a convert to lambda-ism
 
In article <ibq5hb$eac$1@news.albasani.net>, Lew <noone@lewscanon.com>
wrote:

> I've been perusing
> <http://cr.openjdk.java.net/~mr/lambda/straw-man/>
>
> For the first time in the closures debates, I'm a fan of lambda expressions
> in
> Java now.
>
> Not that I've ever been against them, really, just haven't missed them
> before.
> At this point the state of Java discourse around closures has matured to
> where I see clear value in the proposal. It appears that the straw-man
> proposal integrates, or at least aims to integrate the best of all the major
> proposals.
>
> From the link, 2009/12/10:
> "This proposal builds upon the past work of Gilad Bracha, Neal Gafter, James
> Gosling, and Peter von der Ahé on BGGA; of Bob Lee, Doug Lea, and Josh Bloch
> on CICE; and of Stephen Colebourne and Stefan Shulz on FCM. There is little
> here that is new beyond the synthesis of selected elements of those, and
> related, proposals."
>
> I note that this positive progress is happening under Oracle's aegis, and is
> projected for Java 8. Yes, that's right, they're planning an 8.


It's awesome that Java will finally support function pointers elegantly.
Creating an interface or enum just to define a wrapper for a function is
cumbersome in many ways.

I'm a little worried about the proposed Lambda syntax having too much
redundancy with regular functions and methods. There should be only one
way to write it, else there's risk of Java getting cluttered up like
C/C++.

(Still hoping for unsigned math and contiguous object array allocation)
--
I will not see posts or email from Google because I must filter them as spam

Joshua Cranmer 11-15-2010 05:07 AM

Re: a convert to lambda-ism
 
On 11/14/2010 09:22 PM, Lew wrote:
> I've been perusing
> <http://cr.openjdk.java.net/~mr/lambda/straw-man/>
>
> For the first time in the closures debates, I'm a fan of lambda
> expressions in Java now.


The best thing I can say is that it doesn't have BGGA's fanatical
devotion to non-local control flow idioms. Those made a lot of the stuff
just plain complex and confusing, and that alone was enough to sink the
proposal for me.

Now that it looks like the pro-closure camp isn't adhering strictly to
BGGA, I'll revisit my opinions on closures in Java.

I'm not crazy about the syntax, but then again, function pointers have
never had stellar syntax. int (*fp)(int, int), anyone? :-) The ability
to just have single expressions I'm not entirely sure about-- #() {
return x + x; } isn't much longer than #()(x + x), and is certainly
somewhat easier to read.

Another minor syntactic note is that introducing the new keyword
`shared' (or rather, introducing it non-breaking ways (!)) seems
unwarranted. If the idea is to limit to the enclosing scope, you could
probably have the same effect if you reused the keyword `public'.

In terms of major semantic concerns, the big question to me is how to
handle the types. How they are actually implemented does leave major
concerns other some generics interactions due to erasure.

I'm also not sure about the extensions method section. While I have had
instances where I would have liked to use it, it's never been a dealbreaker.

All in all, I'll change my stance from `NO!' to `Maybe?'. Although if
enough howling brings back non-local control flow idioms, I'll change it
back to `NO!'.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

Lew 11-15-2010 01:26 PM

Re: a convert to lambda-ism
 
Kevin McMurtrie wrote:
> (Still hoping for unsigned math and contiguous object array allocation)


IIRC, unsigned ints are on the table for Java 8, due out right about the end
of the Mayan calendar.

--
Lew

Tom Anderson 11-15-2010 05:27 PM

Re: a convert to lambda-ism
 
On Mon, 15 Nov 2010, Joshua Cranmer wrote:

> On 11/14/2010 09:22 PM, Lew wrote:
>> I've been perusing
>> <http://cr.openjdk.java.net/~mr/lambda/straw-man/>
>>
>> For the first time in the closures debates, I'm a fan of lambda
>> expressions in Java now.

>
> The best thing I can say is that it doesn't have BGGA's fanatical devotion to
> non-local control flow idioms.


Yes. I literally punched the air when i read:

There is no non-local transfer of control in this proposal, in contrast
to BGGA.

I thought i was the only one who thought the 'return returns from the
enclosing scope' was batshit insane.

> Those made a lot of the stuff just plain complex and confusing, and that
> alone was enough to sink the proposal for me.


Amen to that, brother. Also, it had maximally horrid syntax. Even
Reinhold's 'strictly provisional' syntax is better!

> I'm not crazy about the syntax, but then again, function pointers have
> never had stellar syntax. int (*fp)(int, int), anyone? :-) The ability
> to just have single expressions I'm not entirely sure about-- #() {
> return x + x; } isn't much longer than #()(x + x), and is certainly
> somewhat easier to read.


The terseness lends itself to the typical higher-order-function uses,
like:

List<String> names;
List<Integer> lengths = names.collect(#(String s) (s.length()));

Adding the return to that makes it noticeably, although of course by no
means fatally, clunkier.

> Another minor syntactic note is that introducing the new keyword
> `shared' (or rather, introducing it non-breaking ways (!)) seems
> unwarranted. If the idea is to limit to the enclosing scope, you could
> probably have the same effect if you reused the keyword `public'.


Agreed.

And i'm surprised non-shared closed-over variables aren't required to be
declared final, but must only be 'effectively-final'. That seems
un-javalike.

> In terms of major semantic concerns, the big question to me is how to
> handle the types. How they are actually implemented does leave major
> concerns other some generics interactions due to erasure.


Could you expand on that? I don't know how to even begin thinking about
the interaction with types.

Mind you, having seen what's happened to the type system around
invokedynamic, i am no longer sure that such concerns are actually a
roadblock to implementation, sadly.

> I'm also not sure about the extensions method section. While I have had
> instances where I would have liked to use it, it's never been a
> dealbreaker.


Given that we won't be able to add lambda-aware methods to existing
collection interfaces, because that would break all existing code which
implements them, extension methods are the only way of being able to write
the example i give above, or do anything along those lines (map, filter,
reduce, and friends). Having lambdas but not being able to do those things
would be agonizing.

Also, i really don't like the implicit function conversion. I appreciate
that there are millions of places where we'd like to use first-class
functions where we currently use these 'SAM' (Single Abstract Method - i
had to look it up) types, but i don't think we should be catering to that
in the language. For the most part, the classes which currently demand SAM
types are ones in the standard library (Collections, Arrays, Thread) which
could easily be enlarged to take lambdas too. Where there are interfaces
which we'd like to expand, we can use extension methods:

package java.util.concurrent;

public class ExecutorService {
public static Thread newThread(ThreadFactory self, #void() fn) {
return self.newThread(new Runnable() {
public void run() {
fn();
}
});
}
}

import static ExecutorService.newThread extends ThreadFactory; // my suggestion

ThreadFactory factory;
Thread t = factory.newThread(#() {doStuff();});

There are tons of other things extension methods would be useful for. I
think once you had them, you'd wonder how you ever lived without them. For
instance, you'll immediately be able to say:

import java.util.List;
import static java.util.Collections.sort extends java.util.List;

List things;
things.sort();

Wouldn't that be nice?

tom

--
We don't contact anybody or seek anybody's permission for what we do. Even
if it's impersonating postal employees. -- Birdstuff

Tom Anderson 11-15-2010 05:36 PM

Re: a convert to lambda-ism
 
On Sun, 14 Nov 2010, markspace wrote:

> On 11/14/2010 6:22 PM, Lew wrote:
>> I've been perusing
>> <http://cr.openjdk.java.net/~mr/lambda/straw-man/>

>
> I believe the latest draft/update is here:
>
> <http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-3.html>


Urgh. This is even more SAM-centric. Why is it impossible for anyone to
come up with a lambda proposal without latching on to at least one
terrible idea?

The concrete syntax is worse, too.

> The switch from Java 7 to Java 8 happened a while back. Basically, all
> the features planned for Java 7 would have delayed it by at least a
> couple of years. So they broke Java 7 into two parts: the easy bits and
> the hard bits. Easy bits are going out ASAP in Java 7, the harder stuff
> will be delayed and then go out in Java 8.
>
> Weird, but I do think getting something out for Java 7 ASAP was the
> right choice.


Whatever happened to the proud tradition of x.5 releases, eh? Does nobody
remember System 7.5 and 8.5 on the Mac? Are we seriously going to go from
1.6.0 to 1.7.0?

tom

--
I DO IT WRONG!!!

Jim Janney 11-15-2010 07:53 PM

Re: a convert to lambda-ism
 
Tom Anderson <twic@urchin.earth.li> writes:

> On Mon, 15 Nov 2010, Joshua Cranmer wrote:
>
>> On 11/14/2010 09:22 PM, Lew wrote:
>>> I've been perusing
>>> <http://cr.openjdk.java.net/~mr/lambda/straw-man/>
>>>
>>> For the first time in the closures debates, I'm a fan of lambda
>>> expressions in Java now.

>>
>> The best thing I can say is that it doesn't have BGGA's fanatical
>> devotion to non-local control flow idioms.

>
> Yes. I literally punched the air when i read:
>
> There is no non-local transfer of control in this proposal, in contrast
> to BGGA.
>
> I thought i was the only one who thought the 'return returns from the
> enclosing scope' was batshit insane.
>
>> Those made a lot of the stuff just plain complex and confusing, and
>> that alone was enough to sink the proposal for me.

>
> Amen to that, brother. Also, it had maximally horrid syntax. Even
> Reinhold's 'strictly provisional' syntax is better!
>
>> I'm not crazy about the syntax, but then again, function pointers
>> have never had stellar syntax. int (*fp)(int, int), anyone? :-) The
>> ability to just have single expressions I'm not entirely sure
>> about-- #() { return x + x; } isn't much longer than #()(x + x), and
>> is certainly somewhat easier to read.

>
> The terseness lends itself to the typical higher-order-function uses,
> like:
>
> List<String> names;
> List<Integer> lengths = names.collect(#(String s) (s.length()));
>
> Adding the return to that makes it noticeably, although of course by
> no means fatally, clunkier.
>
>> Another minor syntactic note is that introducing the new keyword
>> shared' (or rather, introducing it non-breaking ways (!)) seems
>> unwarranted. If the idea is to limit to the enclosing scope, you
>> could probably have the same effect if you reused the keyword
>> public'.

>
> Agreed.
>
> And i'm surprised non-shared closed-over variables aren't required to
> be declared final, but must only be 'effectively-final'. That seems
> un-javalike.
>
>> In terms of major semantic concerns, the big question to me is how
>> to handle the types. How they are actually implemented does leave
>> major concerns other some generics interactions due to erasure.

>
> Could you expand on that? I don't know how to even begin thinking
> about the interaction with types.
>
> Mind you, having seen what's happened to the type system around
> invokedynamic, i am no longer sure that such concerns are actually a
> roadblock to implementation, sadly.
>
>> I'm also not sure about the extensions method section. While I have
>> had instances where I would have liked to use it, it's never been a
>> dealbreaker.

>
> Given that we won't be able to add lambda-aware methods to existing
> collection interfaces, because that would break all existing code
> which implements them, extension methods are the only way of being
> able to write the example i give above, or do anything along those
> lines (map, filter, reduce, and friends). Having lambdas but not being
> able to do those things would be agonizing.
>
> Also, i really don't like the implicit function conversion. I
> appreciate that there are millions of places where we'd like to use
> first-class functions where we currently use these 'SAM' (Single
> Abstract Method - i had to look it up) types, but i don't think we
> should be catering to that in the language. For the most part, the
> classes which currently demand SAM types are ones in the standard
> library (Collections, Arrays, Thread) which could easily be enlarged
> to take lambdas too. Where there are interfaces which we'd like to
> expand, we can use extension methods:
>
> package java.util.concurrent;
>
> public class ExecutorService {
> public static Thread newThread(ThreadFactory self, #void() fn) {
> return self.newThread(new Runnable() {
> public void run() {
> fn();
> }
> });
> }
> }
>
> import static ExecutorService.newThread extends ThreadFactory; // my suggestion
>
> ThreadFactory factory;
> Thread t = factory.newThread(#() {doStuff();});
>
> There are tons of other things extension methods would be useful
> for. I think once you had them, you'd wonder how you ever lived
> without them. For instance, you'll immediately be able to say:
>
> import java.util.List;
> import static java.util.Collections.sort extends java.util.List;
>
> List things;
> things.sort();
>
> Wouldn't that be nice?


It's just an alternate syntax for calling a static method. And yes,
if you're going to allow that it would be nice if everyone could play,
not just the author of the interface. But without it you could still
write their more complex example as

import static Collections.filter;
import static Collections.map;
import static Collections.reduce;

int ans = reduce(map(filter(s, #(int x)(x != 0)),
#(int x)(x + 3)),
#(int x, int b)(x + b), 0);

This isn't quite as nice as the extension method syntax but it still
isn't too bad. And if you switched the order of the arguments to put
the collection last it could be

int ans = reduce(#(int x, int b)(x + b), 0,
map(#(int x)(x + 3),
filter(#(int x)(x != 0), s)));

--
Jim Janney

Lew 11-16-2010 05:03 AM

Re: a convert to lambda-ism
 
Lew wrote:
>> IIRC, unsigned ints are on the table for Java 8, due out right about the
>> end of the Mayan calendar.


Ken Wesson wrote:
> Begging your pardon, but the Mayan calendar ends in only two years. I
> have my doubts whether we'll have a released Java 7 by then, let alone 8.


I said "due", not "guaranteed" or "likely".

--
Lew

Andreas Leitgeb 11-16-2010 11:22 AM

Re: a convert to lambda-ism
 
Tom Anderson <twic@urchin.earth.li> wrote:
> The terseness lends itself to the typical higher-order-function uses,
> like:
> List<String> names;
> List<Integer> lengths = names.collect(#(String s) (s.length()));


I seem to have missed one part of the ("straw man") proposal. Is there any
mention of checked exceptions? Are they just plain forbidden, or is
there some extra syntax for specifying those with lambdas?

> Given that we won't be able to add lambda-aware methods to existing
> collection interfaces, because that would break all existing code which
> implements them, extension methods are the only way of being able to write
> the example i give above,...


I don't quite understand the benefit of those particular extension methods.
My impression is, that once the train leaves its current station "single
inheritence and multi interfaces", there won't be any useful stop before
"multi inheritence". Extension methods look to me just like an extra stop
in the suburbs of "multi inheritence" town, where most of the downsides (like
the much more complicated method-resolution) are already pressing, but most
of the uses are deliberately withheld. What's the benefit of deferring to
a separate static method as opposed to implementing the default directly in
the same interface?

> Also, i really don't like the implicit function conversion. [...]


Not doing it that way now, will likely lead to it being added later as a
syntactic sugar to remove the highly redundant boilerplate idiom
new MySAMInterface() { public RetType sm(ArgTypes a) { return lambda(a); } }

How do you feel about the other direction, allowing appropriate SAM-class's
instances to be passed for lambda-arguments?



All times are GMT. The time now is 09:21 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.