It seems to me that macros are defined much too often in the Julia ecosystem and the (error-prone) definitions of such macros are often very complex.
FWIW, the Julia Manual page on metaprogramming already heavily discourages defining macros:
evaland defining new macros should be typically used as a last resort.
It seems to me that (almost?) the only good way to design a package that includes macros is like this:
- the macro simply provides some syntax sugar over an actual Julia function, with only minimal logic used in the definition of the macro itself
- if the macro is part of the public API, the function that the macro wraps should also be public (with
export, in future Julia versions) and documented
Even if these rules were followed, each macro introduces its own syntax on top of Julia, causing extra cognitive load for the programmer and trouble for tooling, meaning that both macro usage and macro definition should perhaps be discouraged to a degree within public packages, even if a macro/DSL is sometimes really necessary.
One way of discouraging unnecessary definition of macros would be to disable automatic merging (automerge) for General registry packages when the package includes a macro definition (perhaps with the restriction that the macro name is public instead of just internal). Another potentially good restriction would be to whitelist macros that define new string literals. @ShalokShalom suggests that it may be better to just give some kind of warning/tag.
A more conservative approach would perhaps be to only do this when the definition of the macro crosses some complexity threshold.
Are these ideas good?