Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: Steven Simpson Newsgroups: comp.lang.java.programmer Subject: Re: new Java lambda syntax Date: Sun, 11 Sep 2011 17:18:17 +0100 Organization: Aioe.org NNTP Server Lines: 129 Message-ID: <9j3vj8-aqe.ln1@news.simpsonst.f2s.com> References: NNTP-Posting-Host: r+C7JLFxs5GRD6HZueZLYg.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 X-Notice: Filtered by postfilter v. 0.8.2 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:7806 On 11/09/11 13:06, Tom Anderson wrote: > On Sat, 10 Sep 2011, Steven Simpson wrote: >> * 'effectively final' - A non-final local variable can be immutably >> captured by a lambda, so long as it's shown not to be assigned to >> subsequently. > > Seems sensible. I would have been happy with a requirement for > explicit finality, but i recognise that many people would have been > annoyed by it, and i don't think this introduces any danger. Any idea > how hard it is for the compiler to prove that the variable cannot be > modified? Hmm, it's more strict than I thought (but easier to compile). It seems you have to be able to add final to the variable declaration. This compiles fine: void func() { int i = 0; Runnable action = () -> { System.out.println(i); }; } ...but any assignment to 'i', before or after creating 'action', prevents 'i' from being effectively final. Hardly a disaster. :-) >> * 'long this' - In the body of a lambda, 'this' has the same meaning >> as it would in the enclosing scope. It does not refer to the >> object that ultimately fulfils the lambda. > > Also seems sensible. Are there any cases where you would want to refer > to the lambda object itself? I'm sure people will come up with them > once lambdas come into use. Will there be any way to get hold of such > a reference? Some corner cases came up, along with some work-arounds. They were probably recursive. I think assignment rules were altered slightly so that a lambda body could refer to itself: Runnable x = () -> { x.run(); }; It was deemed okay to allow this because you can be certain that x will be ready before it is run. >> * 'throws T' - A set of exceptions can be expressed as a generic >> type parameter, so they can be relayed from the lambda's signature >> to the signature of the method that calls it. > > Oh, cool. Yes, except I'm not sure how useful it will be in practice with concurrent APIs. With a serial contract, like a library version of the for-each loop, it's clearly useful: interface Block { void apply(E val) throws T; } static void forEach(Iterable coll, Block block) throws T { for (Iterator iter = coll.iterator(); iter.hasNext(); ) { E elem = iter.next(); block.apply(elem); } } Now the forEach method can generically throw the same set of exceptions T that the block itself can throw. But if there is no serial guarantee on invoking the block, you have to choose whether you return arbitrarily just the first exception thrown, or pack them into some structure, or something else. I've a feeling that, most of the time, such methods will require the SAM type to throw nothing, so won't get used. >> It could be argued that these restrictions seem to reduce lambdas to >> just a shorter syntax for certain anonymous inner classes. However, >> I think there's an aspiration to implement them more cheaply than >> normal objects. > > I'd be happy with them actually being syntactic sugar for anonymous > classes (i am quite unsophisticated my tastes!). The VM boffins could > then focus on making anonymous classes cheaper in general. I think they don't foresee such savings for anon classes generally, because they potentially have fields and multiple user-defined methods. When you're certain such complexities don't exist, which is the case for lambdas, certain optimizations become possible. >> There are no automatically generated families of function types >> (yet), so you have to rely on SAM (single abstract method) types. >> Lambdas are just a syntactic construct until you've expressed or >> implied the SAM type, with an assignment, initialization or a cast. > > Oh, wait, what? Wow. There's no function type? So you can *only* use > lambdas as SAMs? Have i understood that correctly? That's kinky. You seem disturbingly excited by that! :-) Here are some arguments about it (not necessarily mine): * Function types would introduce a form of structural typing, which is a little alien to Java. We saw a thread here just a few days ago ("simple method to simulate function pointers in java"), where someone was hand-crafting generic function types, and some of the advice was just to define interfaces per situation, partly because it documents better, and partly because it's more idiomatic for Java. * Function types could be added in such a way that they would be SAM types, so if you can get lambdas to work with SAM types (which you'd probably have to do anyway to take advantage of old APIs), they should automatically work with function types added later. * A limited number of generic SAM types are being defined to extend the Collections API. They will probably serve as well as function types in the most common cases. * If a lambda is always typed as a SAM, how you invoke it is settled - it's the name of the SAM's method, of course. I recall seeing proposals where you could write obj(args), or obj.(args), or obj.invoke(args), where obj was a function type. Leave it as a SAM, and you don't have to make a decision about that. > You say 'yet' - can we expect function types before it's finished? IIRC, no plans for Java 8 - back burner, I think. ISTR some difficulties arose, so maybe they decided they needed more time for something deemed not essential. -- ss at comp dot lancs dot ac dot uk