Is evaluating a quoted expressions of nested DSL calls also considered as a bad practice?

From what I understand calling this function will literally evaluate that AST at compile-time, imagine you have the following:

a = 10
b = 20

quoted = quote do a + b end

{:+, [context: Elixir, imports: [{1, Kernel}, {2, Kernel}]],
 [
   {:a, [], Elixir},
   {:b, [context: Elixir, imports: [{1, IEx.Helpers}]], Elixir}
 ]}

# Evaluating this will result in an error
Code.eval_quoted(quoted)

This will always result in an error, because the values don’t exist from the context you are trying to evaluate the expression (unless you define them manually in that context), hence composition of AST, that will be executed later by the compiler in the correct context is recommended instead of its evaluation at compile-time.

If you want to do so then you can use bindings parameter which defaults to []. In my case it’s not a problem.

defmodule MyLib do
  defmacro root_dsl(do: block) do
    Process.put(:nested_values, [])
    Code.eval_quoted(block, [], __CALLER__)
    values = Process.get(:nested_value)
    processed_values = Enum.map(values, &process/1)

    quote bind_quoted: [values: processed_values] do
      for value <- values do
        def some_function(unquote(value)), do: {:ok, value}
      end
    
      def some_function(value), do: {:error, "incorrect value: #{value}"}
    end
  end

  defmacro nested_dsl do
    value = # …
    values = Process.get(:nested_value)
    Process.put(:nested_values, [value | values])
    nil
  end
end

Look that there is no use of module attribute. Only current process at compilation time stores the values, most of the logic happens in root_dsl macro and the block in quote call is as simple as possible.

Without Code.eval_quoted/3 it would look like:

defmodule MyLib do
  defmacro root_dsl(do: block) do
    [
      quote do
        Process.put(:nested_values, [])
        unquote(block)
      end,
      quote unquote: false do
        values = Process.get(:nested_value)
        processed_values = Enum.map(values, &process/1)

        for value <- processed_values do
          def some_function(unquote(value)), do: {:ok, value}
        end
        
        def some_function(value), do: {:error, "incorrect value: #{value}"}
      end
    ]
  end

  defmacro nested_dsl do
    quote do
      value = # …
      values = Process.get(:nested_value)
      Process.put(:nested_values, [value | values])
    end
  end
end

Of course it’s just an example, but it shows really well how version with Code.eval_quoted/3 looks better. The question is if it’s anyway seen as a bad practice and if so why …

I mean that is just a generic warning, you can do whatever you want in your macros.

I personally would say that using Code.eval_quoted/3 inside of your macros is an imperative way of doing things and composing the AST is the declarative way, as you are composing a data structure that is later evaluated.

I don’t have experience doing this kind of shenanigans, however I would suspect you running into trouble with evaluation contexts sooner or later when you are doing this kind of intermediary evaluations of code.

Exactly, I was asking if this is too generic and therefore my use case should not be considered as a bad practice.

Including bad practices … For example I don’t have to follow credo -. I want to follow it. I was asking if what I’m thinking about makes sense.

Yeah, that’s why I’m not considering it in every case, but the one like this one i.e. when I want to evaluate code as-is without any bindings or expectations what is in the evaluated code especially if I have to collect data passed as macro arguments and create a nested structure. In example above if there would be no calls to a nested_dsl macro then nested_values stored in current Process would default to empty list [] as it was done before evaluating (just to simplify prepending to list i.e. [head | tail] notation). I’m not seeing a problem here, but still prefer to ask just in case.

Thanks for your opinion!