My point is that you should use **neither** `eval(Meta.parse(...))`

(which is slow) nor `getfield(@__MODULE__, Symbol(...))`

which is faster but still slow.

The `eval(Meta.parse(@sprintf(...)))`

answer was the *literal* answer to your question (how can you evaluate the output of `@printf`

as code), but you are probably asking the wrong question. This is a classic XY problem.

Since I don’t know what your ultimate goal is, I can only give a made-up example. Suppose you want to write a function `integrate(f, a, b; N=100)`

that computes \int_a^b f(x) dx for a user-specified function `f`

from `a`

to `b`

using an `N`

-point trapezoidal rule. You could implement this with:

```
function integrate(f, a, b; N=100)
dx = (b - a) / (N-1)
I = (f(a) + f(b)) * dx / 2 # endpoints
for i = 1:N-2 # interior points
I += f(i * dx) * dx
end
return I
end
```

This is a “higher-order function” because it takes in a *function* `f`

as an argument. For example, we could use this to approximately integrate your function `DeltaAI`

from 0 to 1:

```
julia> integrate(DeltaAI, 0, 1)
0.6931535573789361
```

which matches the exact answer \ln 2 \approx 0.6931471805599453 to four digits, and we can get more digits correct by increasing `N`

:

```
julia> integrate(DeltaAI, 0, 1, N=10^6)
0.6931471805600137
```

Notice how we can simply pass `DeltaAI`

as an argument. No string evaluation etcetera is required, and Julia compiles this to very efficient code. We can even define new functions on the fly to integrate, e.g.

```
julia> integrate(x -> x^2, 0, 1) # ∫x² ≈ 1/3
0.3333503384008435
```

In this way, functions are “first-class” objects in Julia — you can pass them as arguments, return them from other functions, manipulate them to make new functions, etcetera, on the fly.

You wouldn’t store numbers as strings in Julia. Don’t store functions as strings either.