Reexport functionality.

[lassepe]

First of all, thank you for this awesome package. It is a great prototype of saner code loading and I have really enjoyed it so far.

I was wondering whether it makes sense to add some reexport functionality to this package. I find my module file consisting solely of code like

module MyModule

using FromFile: @from

@from "foo.jl" import foo, bar, baz
export foo, bar, baz

...
end # module

Thus, it would be nice to have a re-export capability on this level. Maybe this is also beyond the scope of this package and would come more naturally if similar syntax would make it into Base. In that case the requested functionality would perhaps be best added to Reexport.jl. But until then, if it ever happens, it may be nice to have this functionality here.

[patrick-kidger]

Are you suggesting something like

@from_export "foo.jl" import foo, bar, baz

that combines @from and export together?

That seems reasonable -- I think we'd be happy to accept a PR on that.

[lassepe]

Yes, something along that line. Maybe more readable: @from "foo.jl" export foo, bar, baz. But that may also be confusing. Either way seems reasonable.

[patrick-kidger]

Ah, yes. I agree that would be the neatest syntax. As I say, happy to accept a PR on that.

[lassepe]

I'm happy to compile PR. I'll have to catch up on meta programming first though.

[Roger-luo]

Ah, yes. I agree that would be the neatest syntax. As I say, happy to accept a PR on that.

It's shorter but I think this could be ambiguous, it's not obvious to me whether the exported symbols get into the current module scope:

1. it doesn't look like importing bar and baz to the current name scope, thus the effect of importing them into the current module sounds like an implicit behavior
2. however if this statement doesn't import bar and baz, then it seems to be as same as just writing import and export directly

---

A more explicit syntax could be

@from "file.jl" import foo, baz export ...

I believe the major problem of @from "file.jl" export foo, baz is that it doesn't show what is imported explicitly. trade explicity for a shorter statement might not be a good idea.

---

or just support a @reexport macro here that accepts both module and file path

@reexport "file.jl"
@reexport A

I think this is probably the cleanest syntax since Julia itself doesn't have the reexport syntax, and it is consistent with the proposal that treating "file"s as "module"s

[patrick-kidger]

It's shorter but I think this could be ambiguous, it's not obvious to me whether the exported symbols get into the current module scope:

These are reasonable points. Personally I think I'd still prefer it over @from "file.jl" import foo, baz export ... -- that's starting to touch on the discussions over in JuliaLang/julia#39235 about the ... syntax -- but no strong feelings there.

or just support a @reexport macro

I do feel quite strongly that this would be the wrong way to go.

One of the big advantages of the current approach is that it's made explicit what is imported/exported. I find this is consistently a huge help when navigating a code base. Something like this would mean we lose that advantage.

[lassepe]

I like the @from "file.jl" import foo, baz export ... syntax.

I agree that a plain @reexport "file.jl" would be too implicit and it would not be clear where a function is coming from. Also, this kind of functionality is already more or less provided by Reexport.jl. Further, I also agree that @from "file.jl" export foo, baz is too concise.

[lassepe]

To that point, can a syntax like export ... even be used? That is, is it allowed by the parser? It seems like I can't even construct the following expression:

julia> :(export ...)
ERROR: syntax: invalid identifier name "..."
Stacktrace:
 [1] top-level scope
   @ none:1

[patrick-kidger]

Okay, that's kind of fun. Playing with this a bit:

julia> x = :(exporta ...)
:(exporta...)

julia> x.head
:...

julia> x.args
1-element Array{Any,1}:
 :exporta

julia> y = :(export asdf)
:(export asdf)

julia> y.head
:export

julia> y.args
1-element Array{Any,1}:
 :asdf

julia> :(exporta asdf)
ERROR: syntax: missing comma or ) in argument list
Stacktrace:
 [1] top-level scope at none:1

That is to say, :(export asdf) and :(exporta ...) both parse, but neither :(export ...) nor :(exporta asdf) parse. Moreover :(export asdf) and :(exporta ...) have very different parses.

There's also this:

julia> :(.)
:.

julia> :(..)
:..

julia> :(...)
:...

julia> :(....)
ERROR: syntax: invalid identifier name "..."
Stacktrace:
 [1] top-level scope at none:1

Off the top of my head I'm not familiar with the details of what's going on here. Probably we'd need to experiment a bit to figure out what's going on.

Which, incidentally, is an answer to your question over in #26 -- my own experience with Julia metaprogramming has been mostly a trial-and-error process of seeing what works. Beyond that there is the devdocs on the AST. This short discourse thread is also interesting.

[Roger-luo]

One of the big advantages of the current approach is that it's made explicit what is imported/exported. I find this is consistently a huge help when navigating a code base. Something like this would mean we lose that advantage.

I see your point, one may only want to export a selected list of names from one file, now I see @reexport_from as a temporary solution until we figure out better syntax.

[lassepe]

As stated in #26 I think it makes sense to move this feature to Reexport.jl. Thus, I'm closing this issue.

[lassepe]

Reexport 1.2 now is composable with @from