make macros generic functions

[JeffBezanson]

Here's another tidbit from jb/functions that's easy to apply to master.

fixes #9627, #8846, and #8701, and might help #3377

[quinnj]

Seems like a first-class kind of solution 😎

[StefanKarpinski]

Love it. Since all the tests pass, should we merge this?

[mlubin]

Nice!

[tkelman]

If it fixes that many issues, could use a few more test cases couldn't it?

[mbauman]

Probably could use a NEWS entry, too. This is very nifty:

julia> macro foo(x::Int)
           :($x + 1)
       end
@foo (macro with 1 method)

julia> macro foo(x::Symbol)
         @show x
       end
@foo (macro with 2 methods)

julia> @foo 1
2

julia> @foo show
x = :show
show (generic function with 122 methods)

julia> @foo 1+2
ERROR: MethodError: `@foo` has no method matching @foo(::Expr)
 in eval at ./boot.jl:265

[timholy]

Pretty awe-inspiring that this comes with a net reduction of 13 lines of code, and a churn < 100 lines.

[tkelman]

Merging this appears to have introduced a failure on 32 bit appveyor: https://ci.appveyor.com/project/StefanKarpinski/julia/build/1.0.12336/job/smqeb0ravuyaroa3

[yuyichao]

Hmm, I've seen this failure appears on #14541 lin32 for some time and haven't been able to figure out why. I suspect it's related to the IOContext/ImmutableDict and very likely also related to the UndefRefError in dict test and a similar one I've just reproduced repeatedly on ARM.

[Ismael-VC]

I understand that this would replace generated functions, am I right?

On generated functions:

These have the capability to generate specialized code depending on the types of their arguments with more flexibility and/or less code than what can be achieved with multiple dispatch.

Edit: changed generic fucntions to generated functions, sorry ...muscle memory.

[JeffBezanson]

No, after this macros are basically the same as they always were. But the implementation is changed so that a bit more flexibility exists, e.g. having separate definitions for cases with different numbers of arguments.

[iamed2]

@JeffBezanson but @mbauman's example would suggest that they are not the same as they always were? In that you can now have different implementations for different input types.

[JeffBezanson]

Yes, but for the types of the expression objects, not the types of run time values. So the types are almost always just Expr.

[iamed2]

Ah, understood. Thanks.

[Ismael-VC]

Yes, but for the types of the expression objects, not the types of run time values. So the types are almost always just Expr.

Oh! that makes a lot of sense now, thank you very much!

[MichaelHatherly]

Super cool! Unless I've missed something we can't extend a macro without first explicitly importing it, ie.

module A

macro m(x::Int)
    "an integer"
end

end

# I'd expect this to work as it does for methods
macro A.m(x::Expr)
    "an expression"
end

# but it throws a
#
# ERROR: syntax: invalid macro definition
#  in eval at ./boot.jl:265

# this does work as expected though
import .A: @m
macro m(x::Expr)
    "an expression"
end

julia> @m 1
"an integer"

julia> @m 1 + 2
"an expression"

Would it be too greedy to ask for macro A.m syntax as well? :)