If this is in global scope. Use eval. If this is local scope, it’s impossible and won’t be possible. Use a Dict with String as keys to hold the value instead.
[quote=“yuyichao, post:4, topic:3001, full:true”]
If this is in global scope. Use eval. If this is local scope, it’s impossible and won’t be possible. Use a Dict with String as keys to hold the value instead.
[/quote]
Found a “solution” in local scope by widening the field of permissible functions. In my setting “AA” and “BB” represent those short-strings yet to be fetched var1 = "AA" var2 = "BB"
but on the contrary, x and y are known at coding time
x = 2.0 y = rand(2,2)
An ugly solution may be:
function crazymeta(file) open(file, "w") do f write(f,"$var1 = x\n$var2 = y") end include("$file") return AA * BB end
CC = crazymeta("whatever.jl") print("$CC")
Now AA = 2.0, BB and CC are naturally 2x2 Array{Float64,2}. Would it possible to do something like this print/include trick, but with all steps in memory and reasonably fast?
Well you could use include_string, but include operates at global scope.
In your example, AA and BB will be defined as global variables.
In this case, probably best to go with @yuyichao’s suggestion and use @eval.
var1 = "AA"
var2 = "BB"
@eval $(Symbol(var1)) = x
@eval $(Symbol(var2)) = x
CC = AA * BB
print(CC)
but again, this is not usually the best way to go about things. What are you trying to do? By that I mean your actual goal, for which this metaprogramming may likely not be the best solution for.
I agree that using a Dict is better in most cases. However, by defining a macro it is certainly not impossible to create variables in local scope only. I posted one possible solution in another thread. Or did I misunderstand what you meant?
No it’s impossible to create a variable in local scope from runtime value. You can of course use a macro to translate @m "b" into b = 1 but it’s impossible to make var = "b"; @m var behave like b = 1.
Note that the macro is very unlikely the right solution in the other thread either. It essentially let you spell variable syntax slight differently, like writing "a" = 1 instead of a = 1, which might be cool if you really like quoting but I don’t think that’s what the OP asked about in either thread.
Sorry for nagging, but there is obviously something I still don’t understand. The macro in the other thread seems to work (the function creates a random runtime value and the macro creates a variable with that value in the local scope). Here’s the code:
macro localvariable(s::AbstractString, v::Any)
s = Symbol(s)
esc(:($s = $v))
end
function newtest()
c = rand()
@localvariable("b", c)
println("b in function = $b")
end
newtest()
isdefined(:b) && println("global b = $b")
nothing
I have a use case for which I could probably use strings as variable names. I want to construct a graph with some vertices. Since I want to create them iteratively, I use a for loop here but this doesn’t work as expected.
for i = 1:max_nodes
@eval $(Symbol("V$i")) = ExVertex(i, "V$i")
end
So, I switched back to your primary suggestion of using Dictionaries. So far, they work fine.
vertices = Dict("V$i" => ExVertex(i, "V$i") for i=1:max_nodes)
I am replying here to the person who said never to use “parse”.Please excuse if I’ve put my posting in a wrong place, and move it if you can. If yes, I apologize for not being good at social media.
This response is human, not technical, from an old Assembler Language programmer who even keypunched his own COBOL programs and also wrote supervisor mode Operating System code (MVS) in IBM. Don’t tell persons who have been thru the mill what they cannot do because they’ve had far too much of that from IBM’s (Idiots who Became Manages) and other people who were part of the problem, not part of the solution. If you tell me not to do something, I will want to do it; tell me to do it and I’ll want not to do it. I am a disabled veteran of the Great GOTO War, which left a very bad taste in my mouth. If you tell me that “parse” may not be supported in a future release, I’m all ears to listen to you, because I’ve been burnt by that kind of stuff, too. But “thou shalt not” just reminds me of the True Believers in “Improved Programing Technologies” and my intrusive parents. Respectfully.
@Julialang261, you should tell us more about the interesting “Great GOTO War”.
What about considering a post in the Meta Discussion category? Maybe it would deserve a dedicated “Computing Histories” tag.
While @yuyichao could have given an explanation at the time, instead of just a negative and an alternative, the reason is simple: you are doing a lot of unnecessary work by parsing from a String to get the expression object to be evaluated, using @eval and interpolation allows you to build the expression object directly, without a parsing phase.