Well, g=f->f(`key`); g(getfield(Base, Symbol("r" * "u" * "n")))
4 Likes
I see most of the discussion here is focused on safety or lack thereof for these kinds of features, and I would like to add that in the domain I work one of the reasons I chose Julia was specifically to have access to data driven code generation at runtime. My environment is controlled and safe from external input, and for me this is merely a means of optimizing the execution of my problem.
By way of example, without going into detail, 2 cases where I do this are 1) generating functions to update a data flow graph specialized for each of its input nodes, and 2) generating functions to invoke event types for their specific subscribed handlers, in both cases taking information that is known dynamically and hoisting all dynamic evaluation into 1 static indirection for a generated function.
AFAICT that doesn’t require parsing.
Yes, not at all, but it does require eval and runs into issues with world versions requiring invokelatest
It’s a completely different and unrelated matter for code that’s constructed directly in a controled way rather than taken from arbitrary user input. The latter is all what this issue is about.
Doing dynamic code generation at runtime is also not recommanded and can lead to bad dispatch performance and increasing memory usage since it violates the performance model which assumes a finite set of global statements. It’s much safer/better of course.