Thanks, Jamison. That addresses my use case precisely. I do have have a
fixed, known list at compile time.
This solution is good news. (And I rescind my earlier 'yuk')
On Saturday, July 18, 2015 at 8:23:13 PM UTC-4, Jameson wrote:
>
> I'll walk back a bit of what I said, since I'm not entirely clear on your
> use case. You can use a macro such as:
> @load z
> where the definition of @load is:
> macro load(s)
> :( $(esc(s)) = load(joinpath(loadpath, $(string(s, ".jld")))) )
> end
>
> note that `z` in that case is taken as the literal symbol `:z`, and not
> the value of the (non-existent) variable z.
>
> If you are doing this in the global scope anyways, the following is
> perhaps better style:
> for z in [modules, list]
> @eval $(symbol(z)) = load(joinpath(loadpath, $(string(s, ".jld")))) )
> end
> This code structure is used fairly often in base to generate methods, for
> example.
>
> If you don't have a precise list at compile-time, however, I think the
> dict approach is better purely from an introspection standpoint for the
> user (it's hard to document a non-static interface). But if the interface
> is static, then the above examples should help you get started with
> embedding external resources at compile-time.
>
>
> On Sun, Jul 12, 2015 at 1:55 AM Jeffrey Sarnoff <jeffrey...@gmail.com
> <javascript:>> wrote:
>
>> Jameson, in v0.4 is it best not to care about adding a layer of
>> consolidation that is purely artifact -- If so, well ok and yuk.
>>
>> Some of these named variables are better presented as Dicts of subDicts
>> as that well reflects intrinsic intension.
>> Other of these named variables are more as rooms in a house, they have
>> proximity in common without commonality of purpose.
>>
>> Is there a way of doing as you suggest without forcing externally
>> accessible data vectors to intradict?
>>
>>
>> On Saturday, July 11, 2015 at 8:02:01 PM UTC-4, Jameson wrote:
>>
>>> A macro can't do this since it is strictly a pure source transform (it
>>> cannot access values or variables). `eval` is essentially an escape hatch
>>> to allow you to do anything, including this, but only in the global scope
>>> (and it's generally not recommended).
>>>
>>> it was a design decision in julia not to allow this in local scope.
>>> there are much better ways of solving the problem that don't cause issues
>>> for type inference. I recommend the following solution (in v0.4 syntax):
>>>
>>> Dict{AbstractString, Any}( [ name => jld_load(joinpath(path,
>>> name*".jld)) for name in list ] )
>>>
>>> (not tested, so please forgive any typos)
>>>
>>>
>>> On Sat, Jul 11, 2015 at 5:26 PM Scott Jones <scott.pa...@gmail.com>
>>> wrote:
>>>
>>>> Why are you limiting it to an ASCIIString? variable names in Julia
>>>> frequently have Unicode characters.
>>>>
>>>>
>>>> On Saturday, July 11, 2015 at 4:06:43 PM UTC-4, Jeffrey Sarnoff wrote:
>>>>>
>>>>> I have been trying to loop over variable names available as an
>>>>> ASCIIString vector, using each to generate the corresponding jld datafile
>>>>> path+name and load_ing() the datafile into its original variable name ..
>>>>> should this be done with string->symbol manipulation and/or is a macro
>>>>> required to effect an applicative assignment operator? I need some
>>>>> guidance
>>>>> on how to do it.
>>>>>
>>>>
