Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

import/using search order? #2375

Closed
toivoh opened this issue Feb 20, 2013 · 6 comments
Closed

import/using search order? #2375

toivoh opened this issue Feb 20, 2013 · 6 comments
Assignees
Labels
breaking This change will break code needs decision A decision on this change is needed
Milestone

Comments

@toivoh
Copy link
Contributor

toivoh commented Feb 20, 2013

In the example below are three (top level) modules, ModA, Meta, and ModB. ModB attempts to use the other two.
The trouble is that ModB has an implicit using Base, which shadows the top level Meta module:

module ModA
export myvar_A
myvar_A=5
end

module Meta
export myvar_Meta
myvar_Meta=5
end

module ModB
using ModA, Meta
@show myvar_A
@show myvar_Meta
end

Running this in the repl gives me

myvar_A => 5
ERROR: myvar_Meta not defined

This behavior caused me the trouble in toivoh/Debug.jl#35: Debug.jl has a sub-module Debug.Meta. When Base.Meta was added, it shadowed Debug.Meta for the other Debug sub-modules. In general, it seems to me that the current behavior with implicit using Base risks to break existing code each time an export is added to Base.

My suggestion is to change name lookup within a module according to:

  • No implicit using Base in any module
  • If name lookup fails within a non-bare module, a lookup is made in Base as a fallback.

An alternative would be to change the interpretation of using to provide a fallback only if an identifier is not found in any other way.

@toivoh
Copy link
Contributor Author

toivoh commented Feb 21, 2013

After thinking about this some more, I realized that the current behavior is not a bug. But I do think that a change is motivated not to let the implicit using Base shadow other identifiers, risking to break code each time an export is added to Base. I've updated the issue accordingly.

@JeffBezanson
Copy link
Member

This is really all about the search order for using and import. I agree it seems wrong for import X to snag an X that happens to be visible via using. I'm trying out the idea of simply ignoring using for the purposes of evaluating import paths, and so far it seems reasonable. cc @StefanKarpinski

@JeffBezanson
Copy link
Member

There are some cases where code has relied on the current behavior, e.g. import Sort.lt, where Sort is visible via the implicit using Base. That seems reasonable by itself, but of course it's unacceptable that this prevents you from using a top-level module called Sort. It should probably have to be written import Base.Sort.lt.

@ghost ghost assigned JeffBezanson Mar 23, 2013
JeffBezanson added a commit that referenced this issue Apr 5, 2013
…ax search from Main (the top level).

addresses #2375

this is quite disruptive, but I think I prefer it. after all, most of
the imports in Base are of internal modules, so they should be marked as
such.
@vtjnash
Copy link
Member

vtjnash commented Apr 5, 2013

should this be closed now?

@JeffBezanson
Copy link
Member

Ok, I believe I have the final design for this on the jb/relativeimport branch.

@JeffBezanson
Copy link
Member

merged into master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking This change will break code needs decision A decision on this change is needed
Projects
None yet
Development

No branches or pull requests

3 participants