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.
