Re-exporting one module's symbols from another

[dcjones]

It would be convenient if there were a way to do this.

module A
    export lots, of, stuff
    # ...
end

module B
    using A
    # magically export everything that was just imported from A
end

Doing this explicitly (copy the long list of exports from A into B) is a bit ugly and error prone. I imagine any alternative would involve a new keyword though.

Concretely, Gadfly is useless without symbols from Compose (and probably DataFrames), but a bunch of compulsory using statements isn't great.

[dcjones]

Actually, I would propose altering export's semantics to make this work:

module B
    using A
    export names(A)
end

[johnmyleswhite]

This is a very good point. I've taken to doing using DataFrames at the start of any new package code that has DataFrames as a requirement.

[StefanKarpinski]

This could be done with a macro, but maybe we should provide some syntax for it.

[stevengj]

My suggestion would be exportall A, which would re-export the exported names of A (but not the unexported names!).

[vtjnash]

A potential downside is that it may make discovery of exported names a bit harder. Also, I'm disinclined to support reserving another name exportall. So, alternatively, something like: using A as B with reexport perhaps? Or export A. (a module name followed by a period)?

[stevengj]

using A as B with reexport seems weird to me (and if you are willing to add a reexport keyword, why not reexport A?), but export A. seems fine to me if a bit subtle.

I don't understand your concern about discovery of exported names; could you clarify?

[vtjnash]

Currently, it easy to parse any julia file, search for export at the start of an expression, and interpret the comma-separated list that follows to quickly identify the public interface for a module.

using ... as ... with reexport adds special syntax to using, not a new keyword

[stevengj]

I see, you are worried about manually parsing for exports. It's not too bad with reexport, though—you just need to do the same thing recursively for each reexport.

If you are wedded to using, I would tend to just support using A reexported.

[vtjnash]

I'm just tossing around other proposals for consideration. Very likely, none of them are inherently better. I didn't mean to imply the as ... part was required. using A rexported or using A reexported as B or using A as B reexported would all be valid. Whether this is a single word or a phrase depends on whether we want to be closer to a english sentence or a keyword. I could accept either.

[staticfloat]

I personally kind of like exportall. It's got a nice symmetry with importall.

[simonster]

I made a macro that mostly works for this pupose. I say mostly because relative module syntax does not work. The parser parses @reexport .MyModule as reexport.@MyModule and throws a syntax error on @reexport .MyModule1, .MyModule2. But @reexport MyMod.MySubMod should work.

[jiahao]

If we ever get a resolution of this issue, we would be able to remove hundreds of lines' worth of redundant-seeming exports from Base.LinAlg and then again from Base.