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
>>>>
>>>
