Remove require, import, and maybe importall and merge into using

[quinnj]

From the mailing list:

Stefan:

I think we should do away with import altogether and just have

using Foo
using Foo: bar

The first would load and create a binding for Foo, make it's exports available as "soft" bindings (what using does now). The second would also load and create a binding for Foo, and make bar available as a "hard" binding (what import does now)."

Seems this is still quite a point of confusion for newcomers.

[IainNZ]

We'd need the import Foo functionality too somehow, where you just get the Foo and nothing else

[simonster]

using Foo:?

[vtjnash]

using Foo: Foo?

[ssfrr]

To bind Foo to the Foo module (and nothing else):
import Foo
To bind Foo to module Foo, x to Foo.x, y to Foo.y
import Foo: x, y
To bind Foo to module Foo, and all Foo's exported names are bound unqualified:
import Foo: *

This could be using instead, but I feel like this is more in the spirit of import.

This also removes the distinction between bringing something into scope and making it available for method extension. I personally think that's a good thing and makes the module system more understandable, but I wanted to make sure we brought it up.

[simonster]

There is a strong case to be made that a construct that makes all of a module's exported bindings available should make them soft (using) bindings and not hard (importall) bindings. Suppose module A uses module B and defines foo(::Any). If a later release of module B also defines and exports foo(::Any), you don't want them to clobber each other. You also don't want module B to define foo(::Int) and have module A sometimes call that method instead of the method it defined because it is more specific, or to have to list all of the identifiers you want from module B to avoid importing a single conflicting identifier.

But if you have explicitly listed the identifiers you want to import, then there is never a reason to give a soft binding. Either you are not going to define new methods of an identifier, in which case hard and soft bindings have identical behavior, or you are going to define new methods of it, in which case a soft binding is equivalent to no binding and if you want that behavior you should just remove the identifier from the list.

So, in short, I like @StefanKarpinski's proposal. Conceptually we need both hard and soft bindings, but we can get all useful behaviors with a single keyword.

[ssfrr]

I see your point. In that case I like your proposal that using Foo: (with the colon but no items) seems conceptually consistent. The colon indicates that you're going to limit which symbols to pull in, but you just don't list any.

The empty trailing : looks a little funny, but I think people would get used to it

[StefanKarpinski]

The trouble with the empty trailing colon is that we currently look for a name on the next line – in other words using Foo: is taken to be incomplete.

[quinnj]

Related: #4600

[toivoh]

I know that current Julia practice is to import everything into the
namespace of the current module, but I really think that there should still
be a simple and natural way to import just the name of a module.

I also think that the current overloading of using Foo and using Foo.Bar is
problematic; it looks inside Foo but not inside Foo.Bar (unless Foo.Bar is
a module?)

[kmsquire]

I think in Stefan's proposal, this is addressed with

using Foo: Foo

On Thursday, August 14, 2014, toivoh notifications@github.com wrote:

I know that current Julia practice is to import everything into the
namespace of the current module, but I really think that there should still
be a simple and natural way to import just the name of a module.

I also think that the current overloading of using Foo and using Foo.Bar is
problematic; it looks inside Foo but not inside Foo.Bar (unless Foo.Bar is
a module?)

—
Reply to this email directly or view it on GitHub
#8000 (comment).

[staticfloat]

@kmsquire but what then happens if there is a Foo module inside of the Foo module? That's unfortunately ambiguous.

[vtjnash]

That's a design error (and causes a warning), so it doesn't matter

[BobPortmann]

I like the version proposed by @ssfrr above the best.

[trans]

Is there an underlying convention that packages have one and only one module entry point? -- To import Foo means import module Foo of package Foo. Any other module must be a submodule of Foo. Which means there is an implicit correspondence between package Foo, Foo.jl in the package and the module Foo within it.

I ask b/c I am wondering if import could also be used for local/relative importing. Say a project has src/foo.jl and src/bar.jl then in foo.jl:

import bar

would import from src/bar.jl. This is an improvement over using include because it operates within the module system.