Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 8FB17200BD4 for ; Thu, 1 Dec 2016 12:18:14 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 8DEF2160B25; Thu, 1 Dec 2016 11:18:14 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 3DA14160B0B for ; Thu, 1 Dec 2016 12:18:13 +0100 (CET) Received: (qmail 60421 invoked by uid 500); 1 Dec 2016 11:18:12 -0000 Mailing-List: contact users-help@groovy.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@groovy.apache.org Delivered-To: mailing list users@groovy.apache.org Received: (qmail 60401 invoked by uid 99); 1 Dec 2016 11:18:12 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Dec 2016 11:18:12 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id D6716C1B58; Thu, 1 Dec 2016 11:18:11 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.88 X-Spam-Level: * X-Spam-Status: No, score=1.88 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id SIsqzmJb3skf; Thu, 1 Dec 2016 11:18:09 +0000 (UTC) Received: from mail-wj0-f182.google.com (mail-wj0-f182.google.com [209.85.210.182]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 2013B5F56C; Thu, 1 Dec 2016 11:18:09 +0000 (UTC) Received: by mail-wj0-f182.google.com with SMTP id v7so201369729wjy.2; Thu, 01 Dec 2016 03:18:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=vNDhTyMdyJrH3dCgohaWc8WyOqxprgW8ExG6YmJxTKk=; b=k/eEfYXCXGfhmUrfH71OZGQQbE7ndw2IQgz/QwfzM17MConWtKptIvSjQtl229TzOa 87Vz7uK4m/fEMnvp6bpcyTNm6H6Hwjqf+iIgguh2WsLZZgvpkRnwXdIB5zVdtiHDG999 35j3RmPlTAGSQyaAse+5OWtk1ZHIz9QW0PrEW/DUdCG0Faj+9vpASXe20EMoQJRuoZ/L fh+aCDdaoP3yyAiJMEy88oDbEuEIeA7N1lAYHtBzuAoynRvzMLJI7ANNJikeNe0+zHJ/ ruxYVPD4TN/4p5C9MoZuoMIzP31rE5BLVyZj3lsp5S3H6CJeHjc3hmZJTFDK77VeGLIR 7Q3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=vNDhTyMdyJrH3dCgohaWc8WyOqxprgW8ExG6YmJxTKk=; b=i1dh8n7k30Yc2N/lOsmET65bXpgrRsjTWC/526FNJgEpUSYVQaEGF8JSAqXG9tdj6W 0+f8nUSoNzqAcPWy9F6jf09HfkxJvKCVasFWisL31BFJMvmfANSLgT4uBvEbth2C+MR6 /YBlSgfWD1ZPllo8r7eNJRUlaZV85OxlrNP64U1EzRllUcqP61PVIiQOQKUJ55lkxtd7 kCTzFqbCf9PlHKHU9LFcYZIARMGXAYAF5zNeEAV2L6PWJC9Gt5BT+LBHxnju0/2nTQa0 rj5Qcq8KxLYieoH5bGxlHSyH/eV2uow8YRCAZV21gd6HM7lSF3J5bofURkvBSg2tLcqh haYA== X-Gm-Message-State: AKaTC03jN61pPjf+UEM6d4n2SOyWXwXGPY4ZxeFEtRv5fcqI3fL0tQo6m66EaNBYAiSU4xp1gUYe76/w49YeRg== X-Received: by 10.194.47.138 with SMTP id d10mr36861708wjn.83.1480591085680; Thu, 01 Dec 2016 03:18:05 -0800 (PST) MIME-Version: 1.0 References: <5C676E6359909E478C7B811BDB48CA3555B2FF@CWWAPP478.windstream.com> <5C676E6359909E478C7B811BDB48CA3555B361@CWWAPP478.windstream.com> In-Reply-To: From: Sergei Egorov Date: Thu, 01 Dec 2016 11:17:55 +0000 Message-ID: Subject: Re: Macro methods proposal To: "users@groovy.apache.org" , "dev@groovy.apache.org" Content-Type: multipart/alternative; boundary=047d7b86e786b84035054296f99e archived-at: Thu, 01 Dec 2016 11:18:14 -0000 --047d7b86e786b84035054296f99e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cedric had an idea to include macro methods in 2.5 and re-implement MacroGroovy as a macro method, so I'm reminding everyone about the proposal :) I'm almost done backporting groovy-macro-methods into the groovy-core, will send PR this week so others can review (it's still WIP tho) On Fri, Sep 23, 2016 at 4:54 PM Sergei Egorov wrote: > Unfortunately, it will not work for 100% cases. > > I.e. macro method accepts ConstantExpression. You can't a method in Groov= y > with such constraints. > > Plus, such signature doesn't make sense for IDEs as well, because macro > methods do all the magic when you compile *your* code, not macro method > itself. > > > Sergei > > On Fri, Sep 23, 2016 at 4:46 PM Winnebeck, Jason < > Jason.Winnebeck@windstream.com> wrote: > > Assuming the AST can=E2=80=99t already form the right signature in the JA= R for IDE > to see, I can think of one solution: > > > > public class MacroMethods { > > @Macro public static T safe(T param) { > > def ctx =3D Macros.macroContext > > def exp =3D Macros.getExpression(param) > > //original code from example=E2=80=A6 > > } > > } > > > > In this case, the IDE sees a method with an appropriate signature, and > knows the method returns the same type as the argument, but you still hav= e > access to the macro context via static methods which could be implemented > using thread locals or similar. The signature could also be used to > restrict the type of the expression allowed, although in most cases I=E2= =80=99d > expect Object or a =E2=80=9CT=E2=80=9D to be used. > > > > Jason > > > > *From:* Sergei Egorov [mailto:bsideup@gmail.com] > *Sent:* Friday, September 23, 2016 9:27 AM > *To:* users@groovy.apache.org; dev@groovy.apache.org > *Subject:* Re: Macro methods proposal > > > > Hey Jason, > > > > Left a comment on #3. > > > > Yes, the method signature of Macro methods is not the same as the call > site. But, for the given call site, IDE can easily determine the signatur= e, > and I'm pretty sure it has all the information already. Plus, this is a n= ew > language feature anyway, so IDE will have to support it, at least I see n= o > other options for now. > > See https://github.com/bsideup/groovy-macro-methods-proposal/issues/1 abo= ut > the syntax as well > > > > Macro methods inherit all the rules of Groovy AST transformations - they > work only for Groovy code. > > > > BR, > > Sergei > > > > > > On Fri, Sep 23, 2016 at 4:02 PM Winnebeck, Jason < > Jason.Winnebeck@windstream.com> wrote: > > This is a really cool idea, especially I like the idea of the compile-tim= e > checked ORM example. I wonder whether or not the use in simple cases is > productive given JIT inlining and branch prediction when branching on a > constant, and decided to phrase that question in an issue > https://github.com/bsideup/groovy-macro-methods-proposal/issues/3. > > > > I noticed that the method signature for the macro method does not match > the signature used at the call site =E2=80=93 does this confuse IDEs like= IntelliJ, > or does this actually work properly because ASTs must be in a separate JA= R, > so the @Macro AST has already run to generate a stub with the proper call > signature that the IDE sees? > > > > Last question, is there any interaction with Java? That is, is it possibl= e > for an implementation to provide a =E2=80=9Cnormal=E2=80=9D version of th= e method like in > your =E2=80=9Cwarn=E2=80=9D example so that Java can call it as a normal = method while in > Groovy the transform would be applied? In that way you could make a loggi= ng > library that would work like a normal logging library in Java but in Groo= vy > would apply the macro transformations. > > > > Jason > > > > *From:* Sergei Egorov [mailto:bsideup@gmail.com] > *Sent:* Friday, September 23, 2016 5:58 AM > *To:* dev@groovy.apache.org; users@groovy.apache.org > *Subject:* Macro methods proposal > > > > Hey, everyone. > > > > It's been awhile since last time I participated in Groovy. > > I was mostly in read-only mode for the last two years. > > > > With this move, I hope to change it. > > > > I created a proposal for macro methods (no ETA, initially aimed to 3.0) > because I think they are great for the future of Groovy and compile time > metaprogramming. > > > > You can find the proposal here: > > https://github.com/bsideup/groovy-macro-methods-proposal > > > > Not sure how Apache people will react on it since it's on GitHub, but it > was the simplest way for me to share and discuss it. > > > > Please note that macro methods are not the same as MacroGroovy - another > thing from me already merged to groovy-core. But, MacroGroovy *can* and > *should* be implemented with macro methods. > > > > > > Grammar and clearness are not my strong points, but we can improve the > proposal altogether. > > > > > > For the few years Guillaume, Baruch, Cedric and others were trying to > spread the word about macro methods, but the problem here that they are > something really new and I didn't succeed explained them back in the days= . > > > > > > So, I'm inviting everyone to discuss them, by raising GitHub issues, or > here, in mail list, to make them more clear for everyone, including end > users. > > > > > > Cheers, > > Sergei > > This email message and any attachments are for the sole use of the > intended recipient(s). Any unauthorized review, use, disclosure or > distribution is prohibited. If you are not the intended recipient, please > contact the sender by reply email and destroy all copies of the original > message and any attachments. > > --047d7b86e786b84035054296f99e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Cedric had an idea to include macro methods in 2.5 and re-= implement MacroGroovy as a macro method, so I'm reminding everyone abou= t the proposal :)

I'm almost done backporting groovy= -macro-methods into the groovy-core, will send PR this week so others can r= eview (it's still WIP tho)

On Fri, Sep 23, 2016 at 4:54 PM Sergei Egorov <bsideup@gmail.com> wrote:
Unfortunately= , it will not work for 100% cases.=C2=A0

I.e. macro method accepts Con= stantExpression. You can't a method in Groovy with such constraints.=C2= =A0

Plus, such signature doesn't make sense for IDEs as well= , because macro methods do all the magic when you compile your=C2=A0code, not macro me= thod itself.=C2=A0
<= div class=3D"gmail_msg">

Sergei

On Fri, Sep 23, 2016 at 4:46 PM Winnebeck, Jason <Ja= son.Winnebeck@windstream.com> wrote:

Assumin= g the AST can=E2=80=99t already form the right signature in the JAR for IDE= to see, I can think of one solution:

=C2=A0

public = class MacroMethods {<= /span>

=C2=A0 = @Macro public static <T> T safe(T param) {=

=C2=A0= =C2=A0=C2=A0 def ctx =3D Macros.macroContext

=C2=A0= =C2=A0=C2=A0 def exp =3D Macros.getExpression(param)=

=C2=A0= =C2=A0=C2=A0 //original code from example=E2=80=A6

=C2=A0 = }

}

=C2=A0

In this= case, the IDE sees a method with an appropriate signature, and knows the m= ethod returns the same type as the argument, but you still have access to t= he macro context via static methods which could be implemented using thread l= ocals or similar. The signature could also be used to restrict the type of = the expression allowed, although in most cases I=E2=80=99d expect Object or= a =E2=80=9CT=E2=80=9D to be used.

=C2=A0

Jason

=C2=A0

From: Sergei Egorov [mailto:bsideup@gmail= .com]
Sent: Friday, September 23, 2016 9:27 AM
To: users@groovy.apache.org; dev= @groovy.apache.org
Subject: Re: Macro methods proposal

=C2=A0

Hey Jason,

=C2=A0

Left a comment on #3.

=C2=A0

Yes, the method=C2=A0signature of Macro me= thods is not the same as the call site. But, for the given call site, IDE c= an easily determine the signature, and I'm pretty sure it has all the i= nformation already. Plus, this is a new language feature anyway, so IDE will have to support it, at least I see no other options fo= r now.

See=C2=A0https://github.com/bsideup/groovy-macro-methods-proposal/issues/1=C2=A0about the syntax as well

=C2=A0

Macro methods inherit all the rules of Gro= ovy AST transformations - they work only for Groovy code.=C2=A0

=C2=A0

BR,

Sergei

=C2=A0

=C2=A0

On Fri, Sep 23, 2016 at 4:02 PM Winnebeck,= Jason <Jason.Winnebeck@windstream.com> wrote:

This is= a really cool idea, especially I like the idea of the compile-time checked= ORM example. I wonder whether or not the use in simple cases is productive given JIT inlining an= d branch prediction when branching on a constant, and decided to phrase tha= t question in an issue https://github.com/bsideup/groovy-macro-methods-proposal/issues/3.

=C2=A0<= /span>

I notic= ed that the method signature for the macro method does not match the signat= ure used at the call site =E2=80=93 does this confuse IDEs like IntelliJ, or does this actually= work properly because ASTs must be in a separate JAR, so the @Macro AST ha= s already run to generate a stub with the proper call signature that the ID= E sees?

=C2=A0<= /span>

Last qu= estion, is there any interaction with Java? That is, is it possible for an = implementation to provide a =E2=80=9Cnormal=E2=80=9D version of the method like in your =E2= =80=9Cwarn=E2=80=9D example so that Java can call it as a normal method whi= le in Groovy the transform would be applied? In that way you could make a l= ogging library that would work like a normal logging library in Java but in Groovy would apply the macro transformations.

=C2=A0<= /span>

Jason

=C2=A0<= /span>

From: Sergei Egorov [mailto:bsideup@gmail= .com]
Sent: Friday, September 23, 2016 5:58 AM
To: dev@groovy.apache.org; users@groovy.apache.org
Subject: Macro methods proposal

=C2=A0

Hey, everyone.<= u class=3D"gmail_msg">

=C2=A0

It's been awhile since last time I par= ticipated in Groovy.=C2=A0

I was mostly in read-only mode for the las= t two years.

=C2=A0

With this move, I hope to change it.

=C2=A0

I created a proposal for macro methods (no= ETA, initially aimed to 3.0) because I think they are great for the future= of Groovy and compile time metaprogramming.

=C2=A0

You can find the proposal here:

https://gi= thub.com/bsideup/groovy-macro-methods-proposal

=C2=A0

Not sure how Apache people will react on i= t since it's on GitHub, but it was the simplest way for me to share and= discuss it.

=C2=A0

Please note that macro methods are not the= same as MacroGroovy - another thing from me already merged to groovy-core.= But, MacroGroovy can=C2=A0and should= =C2=A0be implemented with macro methods.

=C2=A0

=C2=A0

Grammar and clearness are not my strong po= ints, but we can improve the proposal altogether.

=C2=A0

=C2=A0

For the few years Guillaume, Baruch, Cedri= c and others were trying to spread the word =C2=A0about macro methods, but = the problem here that they are something really new and I didn't succeed explained them back in the days.=C2=A0<= u class=3D"gmail_msg">

=C2=A0

=C2=A0

So, I'm inviting everyone to discuss t= hem, by raising GitHub issues, or here, in mail list, to make them more cle= ar for everyone, including end users.

=C2=A0

=C2=A0

Cheers,

Sergei

This email message and any attachments are= for the sole use of the intended recipient(s). Any unauthorized review, us= e, disclosure or distribution is prohibited. If you are not the intended re= cipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.<= u class=3D"gmail_msg">

--047d7b86e786b84035054296f99e--