Re: About the callable native lambda

Hi again > On 1 Feb 2018, at 13.48, Jochen Theodorou wrote: > > [...] >> For static compilation, r1() and r2() should work IMHO, and r3() should be >> rejected. This shouldn't surprise anyone, I think. > > you mean because the m has a return value and r3() is void? That is

Re: About the callable native lambda

Am 01.02.2018 um 12:50 schrieb Jesper Steen Møller: [...] class R implements Runnable { void run(){}} def m(Runnable r1, R r2, r3) { r1() r2() r3() } m(new R(), new R(), new R()) Currently, in the 'native-lambda' branch, r1() succeeds, whereas the latter two fail to

Re: About the callable native lambda

(Sorry, first version went out too soon, thanks to the silly, silly Touch Bar) > On 31 Jan 2018, at 23.01, MG wrote: > > Hi Jesper, > > seen from a Groovy user perspective your proposal seems to make sense to me. > (I would at the same time hope you do not dent Daniel Sun's

Re: About the callable native lambda

Hi Jesper, Given `f` is of SAM type, `f(params...)` is actually `f.call(params...)`, which I transform to `f.(params...)` eventually[1]. The reason why I do not choose `f.(params...)` at the beginning is that I'm not sure whether we can get enough type information of `f`, in addition, as

Re: About the callable native lambda

Hi Jesper, seen from a Groovy user perspective your proposal seems to make sense to me. (I would at the same time hope you do not dent Daniel Sun's enthusiasm too much, because as far as I can tell he is currently doing alot of the heavy lifting in this project :-) ) How do you think what

Re: About the callable native lambda

Hi Rémi, As we can see, operandStack.pop() is commented, so the code will not take effect ;) Jochen told me some operands left in the stack, I should have pop them by myself, currently framework pops them for me automatically... so I tried operandStack.pop(), but I got AIOOBE because

Re: About the callable native lambda

- Mail original - > De: "Daniel Sun" > À: "dev" > Envoyé: Mardi 30 Janvier 2018 01:14:25 > Objet: About the callable native lambda > Hi all, > [...] > In addition, have you any idea about the issue[1]? If you do not

Re: About the callable native lambda

Hi Rémi, Thanks for your detailed explanation! > so (2) seems to be a better option. Yeah, I've chosen the option 2 :-) Here is the PR: https://github.com/apache/groovy/pull/654 Welcome to review it ;-) Cheers, Daniel.Sun -- Sent from:

Re: About the callable native lambda

You should try to reuse the LambdaMetaFactory instead of generating your own proxy, - generating a proxy means you have a way to define a class in module that do not own, so you have to use lookup.defineClass (or worst unsafe.defineClass), so you need to generate an invokedynamic - you can

Re: About the callable native lambda

Hi list FYI: This turned into a discussion of the feature itself, on the GitHub commit thread. Basically, I'm proposing changing what "obj(params...)" means: - Non-SAM types: obj(params...) becomes obj.call(params...) - SAM types: obj(params...) becomes obj.(params...) - perhaps only as a

Re: About the callable native lambda

Hi Jesper, I think your suggestion is very nice and I've completed callable native lambda according to option 2 :-) Here is the related commit: https://github.com/apache/groovy/commit/c24c0b7e6a67dcdf277207d4261cfa6f2b55031f Cheers, Daniel.Sun -- Sent from:

Re: About the callable native lambda

Hi Daniel I very much recommend going with option 2: It could and should work for any functional interface, not just the ones implemented in Groovy. Ideally, there would be no difference between a "Java lambda" and a "Groovy lambda" -Jesper > On 30 Jan 2018, at 01.14, Daniel Sun