# Pattern matching for macros

**URL:** <https://discourse.julialang.org/t/pattern-matching-for-macros/21583>\
**Category:** Internals & Design\
**Created:** [March 7, 2019, 3:15pm UTC](https://discourse.julialang.org/t/pattern-matching-for-macros/21583 "2019-03-07T15:15:48Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![ExpandingMan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/expandingman/32/866_2.png) [@ExpandingMan](https://discourse.julialang.org/u/ExpandingMan)\
**Post date:** [March 7, 2019, 2:35pm UTC](https://discourse.julialang.org/t/pattern-matching-for-macros/21583/1 "2019-03-07T14:35:42Z")

</div>

I know that I have brought this up a number of times in these forums, so I hope I’m not becoming annoying, but I can’t help but feel that this falls well short of addressing the real problem of lacking proper pattern matching for writing macros anywhere in `Base` or `stdlib`. (And I am assuming that this suggestion is more about pattern matching blocks than it is about omitting a `begin`.)

I realize that there are many suggestions on these forums about adding things to `Base` or the stdlib which are unwarranted because the suggested functionality is better off in a separate package, but I can’t help but feel that tools for writing easily understandable macro code are a special case, and the existence of this post indicates that others feel the same.

In multiple cases I have found myself in a position of making contributions to packages which contain baffling macro code that is extremely difficult to maintain. It’s not because the authors were bad at writing macro code, it’s rather because with Julia’s complicated AST metaprogramming is simply extremely ugly without special tools, and the authors were either unaware of [MacroTools](https://github.com/MikeInnes/MacroTools.jl) or were nervous about its maintenance (I was explicitly told this by the package authors in at least one case).

I personally would be perfectly happy to continue using [MacroTools](https://github.com/MikeInnes/MacroTools.jl) itself for my own projects, but it seems likely to me that much of the communtiy will remain either unaware of it, or will continue to be unwilling to use it, or perhaps feel motivated to create unnecessary forks. I feel that the proliferation of bewildering, difficult to maintain macro code is very bad for the Julia ecosystem, and I would love if something could be done to “stem the tide” before such code becomes even more prevalant. As you can see from the MacroTools package, pattern matching for metaprogramming doesn’t have to consist of much code itself, but it can save thousands and thousands of lines of confusing, macro code that contributers are afraid to touch.

---

<div class="post-metadata">

**Author:** ![ExpandingMan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/expandingman/32/866_2.png) [@ExpandingMan](https://discourse.julialang.org/u/ExpandingMan)\
**Post date:** [March 7, 2019, 3:02pm UTC](https://discourse.julialang.org/t/pattern-matching-for-macros/21583/2 "2019-03-07T15:02:39Z")

</div>

> [@New syntax for multi-line macrocalls](https://discourse.julialang.org/t/new-syntax-for-multi-line-macrocalls/21571/4):
>
> Actually, I personally did not think of this suggestion as being related to pattern matching, but instead being all about the aesthetics; having a clean way to split arguments to a macro over several lines. That it shares some features with pattern matching is to me tangential

Sorry, I did not mean to try to derail the thread. It seems to me that if you had good pattern matching on blocks, it would obviate the need for a special macro syntax on blocks, which was why I brought it up.

I think it’s a good suggestion, but I would strongly prefer having good pattern matching available to case-by-case special syntax.

---

<div class="post-metadata">

**Author:** ![Evey](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/evey/32/214967_2.png) [@Evey](https://discourse.julialang.org/u/Evey)\
**Post date:** [March 7, 2019, 3:15pm UTC](https://discourse.julialang.org/t/pattern-matching-for-macros/21583/3 "2019-03-07T15:15:48Z")

</div>

> [@New syntax for multi-line macrocalls](https://discourse.julialang.org/t/new-syntax-for-multi-line-macrocalls/21571/5):
>
> Sorry, I did not mean to try to derail the thread. It seems to me that if you had good pattern matching on blocks, it would obviate the need for a special macro syntax on blocks, which was why I brought it up.
> 
> I think it’s a good suggestion, but I would strongly prefer having good pattern matching available to case-by-case special syntax.

No worries! I think good pattern matching is important too, but I see no reason why this suggestion (which is a change to the parser) would in any way negatively influence the adoption of `MacroTools` or a similar package. 😉

---

<div class="post-metadata">

**Author:** ![thautwarm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/thautwarm/32/37760_2.png) [@thautwarm](https://discourse.julialang.org/u/thautwarm)\
**Post date:** [March 7, 2019, 5:46pm UTC](https://discourse.julialang.org/t/pattern-matching-for-macros/21583/4 "2019-03-07T17:46:37Z")

</div>

However, MLStyle.jl just made an advancement.  
[https://thautwarm.github.io/MLStyle.jl/latest/modules/ast/](https://thautwarm.github.io/MLStyle.jl/latest/modules/ast/)  
Just make AST manipulations maintainable.

---

<div class="post-metadata">

**Author:** ![thautwarm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/thautwarm/32/37760_2.png) [@thautwarm](https://discourse.julialang.org/u/thautwarm)\
**Post date:** [March 7, 2019, 5:53pm UTC](https://discourse.julialang.org/t/pattern-matching-for-macros/21583/5 "2019-03-07T17:53:31Z")

</div>

FYI,

[https://www.reddit.com/r/Julia/comments/ap4xwr/mlstylejl\_a\_modern\_way\_to\_manipulate\_asts/](https://www.reddit.com/r/Julia/comments/ap4xwr/mlstylejl_a_modern_way_to_manipulate_asts/)

[Simplify macro rewriters and avoid some prospective bugs by thautwarm · Pull Request #238 · queryverse/Query.jl · GitHub](https://github.com/queryverse/Query.jl/pull/238) ,  
[https://github.com/queryverse/Query.jl/blob/12a1d3c214f42bb63bd18aaa936f127798d74f46/src/table\_query\_macros.jl](https://github.com/queryverse/Query.jl/blob/12a1d3c214f42bb63bd18aaa936f127798d74f46/src/table_query_macros.jl)