Julia: macro qualification inconsistency

[StefanKarpinski]

The way one qualifies macro names seems kind of inconsistent:

import Mod.@foo  # macro import
@Mod.foo         # invocation of unimported macro

Is the @ part of the name or the invocation? Seems like right now it's kind of both which is a bit weird. Tangentially, something I've long wanted is a short form for defining macros along the lines of this:

@foo(ex) = f(ex)

[toivoh]

Yes, it would be great if this could be made consistent! I didn't even know that you could do @Mod.foo, since I thought that you should write the invocation as Mod.@foo (especially since the actual symbol is named @foo, I think.

[JeffBezanson]

Happily, this is not breaking since currently a.@b outside of import just gives an error.

[JeffBezanson]

@foo(ex) = f(ex) is a problem, since this must be interpreted as a call to macro foo on the left side of an =. Indeed this would be very useful for macros that expand into things you can assign to.
You shouldn't be writing so many macros that they need to be one line each! :)

[StefanKarpinski]

You shouldn't be writing so many macros that they need to be one line each! :)

Fair enough.

[StefanKarpinski]

Or maybe we need a @macro macro! :-o

[ihnorton]

Is the old un-imported invocation syntax (@Mod.foo) still necessary? It's only used in one test in base. Of the ~130 packages I have installed, it is used sparingly in: JuMP and MPB, PyCall, FactCheck, ASTInterpreter, ELF, Calculus, BinDeps, TerminalUI, and TexExtensions (mostly once each, except for ~10 uses in the JuMP tests).

(x-ref -users post, #1107)

[yuyichao]

IMHO allowing both @M.foo and M.@foo doesn't seem to be a big problem.

[tkelman]

You need some way of being able to call macros of the same name from different packages. I think M.@foo is a bit more consistent and we could move to deprecate @M.foo if we really felt the need.

[JeffreySarnoff]

do it

[StefanKarpinski]

It's too late now, we're stuck with both syntaxes until 2.0.

[ararslan]

Is there an open issue to track deprecating @M.foo for 2.0?

[StefanKarpinski]

No, I guess we can reopen this and add it to the 2.0 milestone.