You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@groovy.apache.org by Sergei Egorov <bs...@gmail.com> on 2016/09/23 09:58:25 UTC
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
Re: Macro methods proposal
Posted by Sergei Egorov <bs...@gmail.com>.
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 <bs...@gmail.com> wrote:
> Unfortunately, it will not work for 100% cases.
>
> I.e. macro method accepts ConstantExpression. You can't a method in Groovy
> 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’t already form the right signature in the JAR for IDE
> to see, I can think of one solution:
>
>
>
> public class MacroMethods {
>
> @Macro public static <T> T safe(T param) {
>
> def ctx = Macros.macroContext
>
> def exp = Macros.getExpression(param)
>
> //original code from example…
>
> }
>
> }
>
>
>
> 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 have
> 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’d
> expect Object or a “T” 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 signature,
> and I'm pretty sure it has all the information already. Plus, this is a new
> language feature anyway, so IDE will have to support it, at least I see no
> other options for now.
>
> See https://github.com/bsideup/groovy-macro-methods-proposal/issues/1 about
> 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-time
> 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 – does this confuse IDEs like IntelliJ,
> or does this actually work properly because ASTs must be in a separate JAR,
> 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 possible
> for an implementation to provide a “normal” version of the method like in
> your “warn” 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 logging
> library that would work like a normal logging library in Java but in Groovy
> 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.
>
>
Re: Macro methods proposal
Posted by Sergei Egorov <bs...@gmail.com>.
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 <bs...@gmail.com> wrote:
> Unfortunately, it will not work for 100% cases.
>
> I.e. macro method accepts ConstantExpression. You can't a method in Groovy
> 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’t already form the right signature in the JAR for IDE
> to see, I can think of one solution:
>
>
>
> public class MacroMethods {
>
> @Macro public static <T> T safe(T param) {
>
> def ctx = Macros.macroContext
>
> def exp = Macros.getExpression(param)
>
> //original code from example…
>
> }
>
> }
>
>
>
> 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 have
> 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’d
> expect Object or a “T” 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 signature,
> and I'm pretty sure it has all the information already. Plus, this is a new
> language feature anyway, so IDE will have to support it, at least I see no
> other options for now.
>
> See https://github.com/bsideup/groovy-macro-methods-proposal/issues/1 about
> 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-time
> 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 – does this confuse IDEs like IntelliJ,
> or does this actually work properly because ASTs must be in a separate JAR,
> 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 possible
> for an implementation to provide a “normal” version of the method like in
> your “warn” 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 logging
> library that would work like a normal logging library in Java but in Groovy
> 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.
>
>
Re: Macro methods proposal
Posted by Sergei Egorov <bs...@gmail.com>.
Unfortunately, it will not work for 100% cases.
I.e. macro method accepts ConstantExpression. You can't a method in Groovy
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’t already form the right signature in the JAR for IDE
> to see, I can think of one solution:
>
>
>
> public class MacroMethods {
>
> @Macro public static <T> T safe(T param) {
>
> def ctx = Macros.macroContext
>
> def exp = Macros.getExpression(param)
>
> //original code from example…
>
> }
>
> }
>
>
>
> 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 have
> 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’d
> expect Object or a “T” 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 signature,
> and I'm pretty sure it has all the information already. Plus, this is a new
> language feature anyway, so IDE will have to support it, at least I see no
> other options for now.
>
> See https://github.com/bsideup/groovy-macro-methods-proposal/issues/1 about
> 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-time
> 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 – does this confuse IDEs like IntelliJ,
> or does this actually work properly because ASTs must be in a separate JAR,
> 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 possible
> for an implementation to provide a “normal” version of the method like in
> your “warn” 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 logging
> library that would work like a normal logging library in Java but in Groovy
> 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.
>
>
Re: Macro methods proposal
Posted by Sergei Egorov <bs...@gmail.com>.
Unfortunately, it will not work for 100% cases.
I.e. macro method accepts ConstantExpression. You can't a method in Groovy
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’t already form the right signature in the JAR for IDE
> to see, I can think of one solution:
>
>
>
> public class MacroMethods {
>
> @Macro public static <T> T safe(T param) {
>
> def ctx = Macros.macroContext
>
> def exp = Macros.getExpression(param)
>
> //original code from example…
>
> }
>
> }
>
>
>
> 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 have
> 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’d
> expect Object or a “T” 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 signature,
> and I'm pretty sure it has all the information already. Plus, this is a new
> language feature anyway, so IDE will have to support it, at least I see no
> other options for now.
>
> See https://github.com/bsideup/groovy-macro-methods-proposal/issues/1 about
> 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-time
> 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 – does this confuse IDEs like IntelliJ,
> or does this actually work properly because ASTs must be in a separate JAR,
> 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 possible
> for an implementation to provide a “normal” version of the method like in
> your “warn” 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 logging
> library that would work like a normal logging library in Java but in Groovy
> 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.
>
>
RE: Macro methods proposal
Posted by "Winnebeck, Jason" <Ja...@windstream.com>.
Assuming the AST can’t already form the right signature in the JAR for IDE to see, I can think of one solution:
public class MacroMethods {
@Macro public static <T> T safe(T param) {
def ctx = Macros.macroContext
def exp = Macros.getExpression(param)
//original code from example…
}
}
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 have 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’d expect Object or a “T” 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 signature, and I'm pretty sure it has all the information already. Plus, this is a new language feature anyway, so IDE will have to support it, at least I see no other options for now.
See https://github.com/bsideup/groovy-macro-methods-proposal/issues/1 about 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 <Ja...@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 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 – does this confuse IDEs like IntelliJ, or does this actually work properly because ASTs must be in a separate JAR, 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 possible for an implementation to provide a “normal” version of the method like in your “warn” 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 logging library that would work like a normal logging library in Java but in Groovy would apply the macro transformations.
Jason
From: Sergei Egorov [mailto:bsideup@gmail.com<ma...@gmail.com>]
Sent: Friday, September 23, 2016 5:58 AM
To: dev@groovy.apache.org<ma...@groovy.apache.org>; users@groovy.apache.org<ma...@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.
RE: Macro methods proposal
Posted by "Winnebeck, Jason" <Ja...@windstream.com>.
Assuming the AST can’t already form the right signature in the JAR for IDE to see, I can think of one solution:
public class MacroMethods {
@Macro public static <T> T safe(T param) {
def ctx = Macros.macroContext
def exp = Macros.getExpression(param)
//original code from example…
}
}
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 have 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’d expect Object or a “T” 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 signature, and I'm pretty sure it has all the information already. Plus, this is a new language feature anyway, so IDE will have to support it, at least I see no other options for now.
See https://github.com/bsideup/groovy-macro-methods-proposal/issues/1 about 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 <Ja...@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 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 – does this confuse IDEs like IntelliJ, or does this actually work properly because ASTs must be in a separate JAR, 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 possible for an implementation to provide a “normal” version of the method like in your “warn” 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 logging library that would work like a normal logging library in Java but in Groovy would apply the macro transformations.
Jason
From: Sergei Egorov [mailto:bsideup@gmail.com<ma...@gmail.com>]
Sent: Friday, September 23, 2016 5:58 AM
To: dev@groovy.apache.org<ma...@groovy.apache.org>; users@groovy.apache.org<ma...@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.
Re: Macro methods proposal
Posted by Sergei Egorov <bs...@gmail.com>.
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 signature,
and I'm pretty sure it has all the information already. Plus, this is a new
language feature anyway, so IDE will have to support it, at least I see no
other options for now.
See https://github.com/bsideup/groovy-macro-methods-proposal/issues/1 about
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-time
> 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 – does this confuse IDEs like IntelliJ,
> or does this actually work properly because ASTs must be in a separate JAR,
> 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 possible
> for an implementation to provide a “normal” version of the method like in
> your “warn” 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 logging
> library that would work like a normal logging library in Java but in Groovy
> 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.
>
Re: Macro methods proposal
Posted by Sergei Egorov <bs...@gmail.com>.
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 signature,
and I'm pretty sure it has all the information already. Plus, this is a new
language feature anyway, so IDE will have to support it, at least I see no
other options for now.
See https://github.com/bsideup/groovy-macro-methods-proposal/issues/1 about
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-time
> 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 – does this confuse IDEs like IntelliJ,
> or does this actually work properly because ASTs must be in a separate JAR,
> 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 possible
> for an implementation to provide a “normal” version of the method like in
> your “warn” 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 logging
> library that would work like a normal logging library in Java but in Groovy
> 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.
>
RE: Macro methods proposal
Posted by "Winnebeck, Jason" <Ja...@windstream.com>.
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 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 – does this confuse IDEs like IntelliJ, or does this actually work properly because ASTs must be in a separate JAR, 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 possible for an implementation to provide a “normal” version of the method like in your “warn” 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 logging library that would work like a normal logging library in Java but in Groovy 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.
RE: Macro methods proposal
Posted by "Winnebeck, Jason" <Ja...@windstream.com>.
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 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 – does this confuse IDEs like IntelliJ, or does this actually work properly because ASTs must be in a separate JAR, 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 possible for an implementation to provide a “normal” version of the method like in your “warn” 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 logging library that would work like a normal logging library in Java but in Groovy 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.