Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Daniele Futtorovic Newsgroups: comp.lang.java.programmer Subject: Re: new Java lambda syntax Date: Tue, 13 Sep 2011 23:25:05 +0200 Organization: A noiseless patient Spider Lines: 77 Message-ID: References: <9j3vj8-aqe.ln1@news.simpsonst.f2s.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Injection-Date: Tue, 13 Sep 2011 21:29:59 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="XRSCqgy0qluJowbbOaLA6Q"; logging-data="15619"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18MKfB4PUoqVm3PofxdxNWd" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.22) Gecko/20110902 Thunderbird/3.1.14 In-Reply-To: Cancel-Lock: sha1:EMhoQUBPcw2tunb+uIDjWe//NhQ= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:7989 On 13/09/2011 22:22, Joshua Cranmer allegedly wrote: > On 9/13/2011 2:04 PM, Daniele Futtorovic wrote: >> Okay, so you can have a lambda returning a value? Steve Simpson's >> statement: >> >>> There's no (...) long jumps (break, continue, return, throw) >> >> seemed to contradict that, as did Tom's about the "Gafterist nonsense" >> (<3), seeing how Gafter et al.'s proposal contained return values, IIRC. > > What this is referring to is that lambdas do not have non-local control > flow (the so-called "long jump" -- think about C's setjmp/longjmp > feature [1]). Lambdas are effectively "mini-functions", so I could have > a lambda that looked like this: > > (int[] x, int y) => { > for (int i = 0; i < x.length; i++) > if (x[i] == y) return i; > return -1; > }; > > which would effectively be a method that looked like: > int searchList(int[] x, int y) { > for (int i = 0; i < x.length; i++) > if (x[i] == y) return i; > return -1; > } > > In other words, what was not accepted was the thing that pissed me off > about some of the proposals, namely that any block of statements should > do the exact same thing if you wrapped it with ((){/*insert stmt*/})() [2]. > > So this would return true: > boolean foo() { > ((){ return true; })(); > return false; > } > > Obviously, if you want to have more complex logic in the lambda for > returning multiple values other than what you can do in a simple > expression, you'd need some sort of syntax. The compromise then being > discussed would make this method return false: > boolean foo() { > ((){ return true })(); > return false; > } > > .... > > It was at that point that I personally hated non-local control flow in > closures, er, lambdas. [3] > > [1] Actually, don't. It breaks so many things. > [2] This is, supposedly, Tennent's Correspondence Principle. I say > supposedly since a google search only reveals results that are > specifically brought up in reference to the closures debate in JS and Java. > [3] Actually, doing some more research for this posting, it struck me > that the primary rationale for non-local control flow comes from the > heritage of lambdas. Most of the time, lambdas are used in reference to > functional programming paradigms, and in the purer functional languages, > control flow is not done via explicit constructs but rather via specific > function calls. So it's a list.forEach( { body of loop }) as opposed to > a for (Element e : list) { body of loop }; in such languages, non-local > control flow is more important. However, given that Java is more > imperatively structured than functionally structured, non-local control > flow is by means no natural, nor is it necessary to implement, so I > would still stand by my claim that non-local control flow is not a > feature that should be implemented in Java's version of lambdas. For > example, C++11 appears to omit it in their version of lambdas... > Lovely. I welcome that decision, then, and humbly thank you and Tom for your elaborations. -- DF. Determinism trumps correctness.