This is essentially the method used by Python (as I believe I understand
it, import is the worst documented thing in Python). Python puts a
reference to all modules into sys.modules, no matter where they are
imported. And sys.modules is always the first thing searched before path.
So all modules are imported and initialized once (excepting users
explicitly deleteing or reloading). An no matter where the imports happen
the first will actually load and initialize the module and all the others
will just use that copy. But since modules are referenced by sys.modules,
not the top level namespace, there is no pollution until a user explicitly
imports into that namespace.
On Saturday, March 7, 2015 at 5:48:11 AM UTC+10, Josh Langsfeld wrote:
>
> So then your results would indicate that putting 'using MyModule' inside a
> function *could* actually bring the exported names into only the local
> scope *if* the module had already been constructed in the global scope. I
> know I've seen some people discuss name pollution by 'using' too many
> modules. It might be part of a wider solution to enable local scope
> 'using', either with a new keyword or just having 'using' check if the
> module already exists.
>
> On Wednesday, March 4, 2015 at 7:33:37 PM UTC-5, MA Laforge wrote:
>>
>> Josh:
>> I do not fully appreciate the details of how modules get imported
>> either. Here is what I can gather:
>>
>> module moda
>> export modvar, setmodvar
>> modvar = 1
>> setmodvar(x) = (global modvar=x)
>> end
>>
>> module modb
>> export modvar, setmodvar
>> modvar = 2
>> setmodvar(x) = (global modvar=x)
>> end
>>
>> module modc
>> using moda
>> import modb
>> println("using moda")
>> @show modvar, moda.modvar, modb.modvar
>> @show setmodvar(5)
>> @show modvar, moda.modvar, modb.modvar
>> @show modb.setmodvar(3)
>> @show modvar, moda.modvar, modb.modvar
>> end
>>
>> module modd
>> import moda
>> using modb
>> println("using modb")
>> @show modvar, moda.modvar, modb.modvar
>> @show setmodvar(8)
>> @show modvar, moda.modvar, modb.modvar
>> end
>>
>> This gives the following results:
>> using moda
>> (modvar,moda.modvar,modb.modvar) => (1,1,2)
>> setmodvar(5) => 5
>> (modvar,moda.modvar,modb.modvar) => (5,5,2)
>> modb.setmodvar(3) => 3
>> (modvar,moda.modvar,modb.modvar) => (5,5,3)
>> using modb
>> (modvar,moda.modvar,modb.modvar) => (3,5,3)
>> setmodvar(8) => 8
>> (modvar,moda.modvar,modb.modvar) => (8,5,8)
>>
>> So it looks like it is the same code in the background (at least the
>> variables appear to be in a common address space).
>>
>> So... it looks like import merely "makes visible" the code at a module
>> level...
>> And "using" first "imports", then "provides a shortcut" to the exported
>> variables/functions...
>>
>> But as far as I can tell, compilation is done "on demand". I believe
>> that the "real" compile step is done when we call a particular version of
>> the code. Compilation is actually a separate step from "using" and "import"
>>
>>
>> On Tuesday, March 3, 2015 at 11:48:53 AM UTC-5, Josh Langsfeld wrote:
>>>
>>> I'm curious about that workaround suggested in the FAQ, where you wrap
>>> the function inside its own module. What is happening under the hood there?
>>> Does it reinitialize the desired module entirely inside of the wrapper
>>> module or does it just make a reference to some other compiled and
>>> initialized top-level area? This is assuming the module has already been
>>> built elsewhere and you just want easy local access to the exported symbols.
>>>
>>> On Monday, March 2, 2015 at 5:59:30 PM UTC-5, [email protected] wrote:
>>>>
>>>> The C++ "using namespace" and Julia "using module" are not quite the
>>>> same thing. The C++ namespace is a top level entity that is created and
>>>> initialized as part of the C++ startup code and the "using" just makes the
>>>> names of these global entities available within the scope. The Julia
>>>> "using" imports, and thus creates, the module for the first time, and
>>>> Julia
>>>> modules can contain statements that run at initialization, whereas C++
>>>> namespaces can only contain declarations.
>>>>
>>>> But if the Julia "using" is within the function, when should the actual
>>>> import and initialize and execute the statements be done? Every time the
>>>> function is called is very expensive. Hoist the import out of the
>>>> function
>>>> to the top level, but doing this naively (ie putting the hoisted import
>>>> just before the function) will then affect all code following the function
>>>> Have a "pseudo" top- level visible only to the function adds a complete
>>>> new complication to the name management code. But then what happens if
>>>> the
>>>> module is imported into two functions, how is its initialization managed?
>>>> Or the top level and the function?
>>>>
>>>> So for now the "simpler is better" approach is to have the user manage
>>>> importing at the top level only.
>>>>
>>>> Cheers
>>>> Lex
>>>>
>>>> On Tuesday, March 3, 2015 at 7:23:33 AM UTC+10, Josh Langsfeld wrote:
>>>>>
>>>>> It's discussed in the FAQ so there must be a good reason for it,
>>>>> though no rationale is mentioned.
>>>>>
>>>>>
>>>>> http://docs.julialang.org/en/latest/manual/faq/#can-i-use-using-or-import-inside-a-function
>>>>>
>>>>> On Monday, March 2, 2015 at 3:00:21 PM UTC-5, Patrick O'Leary wrote:
>>>>>>
>>>>>> On Saturday, February 28, 2015 at 11:06:38 AM UTC-6, MA Laforge wrote:
>>>>>>>
>>>>>>> C++ provides "using namespace X" to "make available" the contents of
>>>>>>> X to the current scope. This even works on un-named scopes within a
>>>>>>> function:
>>>>>>>
>>>>>>
>>>>>> (etc.)
>>>>>>
>>>>>> I know this is something that's come up before, and I think
>>>>>> rejected--I think because it causes conflicts with multiple dispatch?
>>>>>> But I
>>>>>> can't seem to find the thread(s).
>>>>>>
>>>>>> I can't create a hard conflict in a quick mental search for an
>>>>>> example, but I can create some level of confusion:
>>>>>>
>>>>>> module Foo
>>>>>> bar::Int = 1
>>>>>> end
>>>>>>
>>>>>> module Baz
>>>>>> bar::Float64 = 27.3
>>>>>> with module Foo # not current Julia syntax
>>>>>> bar #which bar is this?
>>>>>> end
>>>>>> end
>>>>>>
>>>>>
