help for macros

[ViralBShah]

The help system needs to work for macros as well:

julia> help(@parallel)
ArgumentError("wrong number of arguments to @parallel")
 in @parallel at multi.jl:1536
 in anonymous at no file
 in event_loop at multi.jl:1626
 in anonymous at no file

[StefanKarpinski]

That's never going to work syntactically, but yes, one ought to be able to look up macros too.

[toivoh]

I get the feeling that macros are not really first class citizens, which is what complicates these sorts of things.

[StefanKarpinski]

I'm not sure it even makes sense to talk about macros being first-class. Are you supposed to be able to pass macros around like functions? That doesn't really mean anything because a macro invocation just means to apply an AST-expander function to some expressions at compile time. So what is the thing? The macro expander function? That is already first-class, just like other functions are, and can be passed around (although I'm not sure what the syntax is for getting it). The invocation itself? That doesn't really make sense as a "thing" that can be passed around (macro calls do appear in ASTs, so they are reified in that way). So what would be first-class?

[StefanKarpinski]

If there was a regex pass in the repl as I suggested in #1460, you could write help @parallel.

[pao]

@help @parallel :D

[StefanKarpinski]

That had occurred to me, but you really want what follows not to have to be proper syntax. I realize you weren't being entirely serious, but it is, of course, something to consider.

[ViralBShah]

@help is not too terrible since it should work for functions too.

[ViralBShah]

Would @help @parallel even work, or would julia try to expand the parallel macro and still give an error?

[toivoh]

Yes, @help @parallel would work -- the macro @help will get the unexpanded AST.

[toivoh]

@StefanKarpinski: I guess the expander function would be first class. You would be able to get it and pass it around.
In some cases it would make sense to invoke it. It should definitely be possible to create a call to it within the AST that you generate from one of your own macros.

As well, julia is a dynamic language, right?
When code is compiled that contains a macro invocation, the reason that it works is because the macro itself has already been encountered, and is bound to the corresponding symbol. It seems to me that I might as well have some initialization code that assigns some macros to the proper variable names (preferably constants) before the code that invokes them gets compiled the first time. But of course I don't know if that's technically possible with julia's design.

The things that you can do with macros are exactly what you need most of the time: define them and apply them,
and import them too. But it seems that any syntax that has to do with macros is a special case. I'm not even sure if @ means "this is a macro" or "apply this macro". I think using and understanding macros would be more transparent if the special syntax was kept to a minimum, and the ordinary ways were used for everything else.

[JeffBezanson]

You can already pass around functions. The whole point of macros is that they behave differently than that. The expander function is an implementation detail; you don't put the function in an AST, because it is a run-time artifact and not a syntax object. The AST for @m x is a macrocall expression with two symbols @m and x as its arguments. That can be built, eval'd, etc. without the macro being a first class object. You can similarly build expressions that define macros.

Given that macros are quite different from everything else, using the same syntax for them as everything else would be even more confusing.