I cannot overemphasize how much I regret allowing this in Absinthe :D. :persistent_term sort of saves my bacon but that required rewriting the whole DSL into something that also operates at runtime which is sort of worth it but now we’re into a whole OTHER discussion of runtime vs compile time DSLs.

Supporting compile time anonymous function is a small nightmare. In the compile time version of Absinthe schemas where they’re compiled to a module body the answer simply is: I don’t. The AST of the anonymous function gets “lifted” up and then dropped into the function body of a __absinthe_function__ clause so that they can be fetched at runtime as part of middleware. In the :persistent_term version I think they get inlined? Honestly I haven’t looked at the details in a while.

Here’s why they’re a nightmare. Let’s take your nice simple example:

  column :name, fn user -> "#{user.first_name} #{user.last_name}" end
  column :email, fn user -> user.email end

And add stuff that as the end user you think should work:

  @prefix :foo
  column :name, fn user -> "#{@prefix} #{user.first_name} #{user.last_name}" end
  @prefix :bar
  column :email, fn user -> "#{@prefix} #{user.email}" end

OR

  prefix =  :foo
  column :name, fn user -> "#{prefix} #{user.first_name} #{user.last_name}" end
  prefix  = :bar
  column :email, fn user -> "#{prefix} #{user.email}" end

OR

  column :name, fn user -> "#{Application.get_env(:my_app, :prefix)} #{user.first_name} #{user.last_name}" end

etc.

These get horrendously tricky to implement because module attributes haven’t actually been executed at the point that your macro is firing, they’ve only become AST itself, and other details depend wildly on how your store your function. It’s even possible to store functions that can’t be used at runtime at all!

Absinthe was built before Persistent term existed. If I could do it all over I’d have a purely functional DSL that just made a nice data structure, and then I’d require that you:

children = [
  ... # ecto goes here
  {Absinthe.Schema, your_schema_builder_result_here},
  # ... Other stuff like phoenix
]

and Absinthe would consume the data stucture emitted by the functional DSL and put whatever structures into :persistent_term it deemed efficient. For Absinthe 2.0 (no immediate plans or timeline) that is exactly what I’ll do. Even for a lot of things like resolvers though it’s just way clearer to point to a “regular” function via &Module.function/3 because there’s no closure over a complicated and often difficult to determine environment.

This is all of a very long winded way of saying: I don’t recommend this style of DSL. Strongly consider other options to avoid it. cc @zachdaniel since he’s done a bunch of similar stuff over in Ash that has at this point far surpassed what I did DSL wise in Elixir.

Honestly we’ve pretty much “figured it out” with our DSL builder Spark. It escapes functions just fine by defining a named function in the module and referencing that. If you have a DSL option type that is a function, this all gets handled for you automagically. You can also use a higher level type {:spark_function_behaviour, behaviour, {function_mod, arity}} that a DSL option can adopt. In that case, you can provide a behaviour and opts pair like @benwilson512 illustrates, or you can provide an anonymous function of a given arity. And it defines a function in the module and references that, passing it to {TheMod, fun: TheFun}.

Spark is still sorely undocumented, but it’s heavily battle tested and has good tests that you can learn from you could build all of absinthe’s DSL or phoenix router in spark with the tools it has today. And we provide an elixir_sense plugin that provides autocomplete with in-line DSL docs with no action required at all.

Edit: link to spark Spark — spark v2.7.2