the initial implementations used to do something in this direction, they relied on multi-methods for dispatching, the issue is that the setup is much harder (because you have to hook many other things). Having a simple map really cleaned up a lot of things, also improves isolation since now the full resolver is contained in that map (without extenal deps, like having it "installed" in the multi-method)

I gotta move now, but I can tell you how to setup with multi-methods, the code still available and will be supported forever (although I like to encourage not doing so, because of the problems described, but still an option)

If you create function during development which keeps creating a new parser then you can just redefine the macro and it will update

That is what we do

So we have something like this:

(defn parser [env query]
  (if utils/dev?
    ((create-parser) env query)
    (parser-inst env query)))

Thanks for the replies! Sorry I didn't see them initially. The recreation of the parser is an interesting angle. I'll explore down that path and see where it gets me.

@U060GQK8U your solution worked quite nicely! Thanks for the suggestion.

Nice! :thumbsup:

re-creating parsers is all fine for dev, but please don't do that in a per request basis in prod, a single parser is better in that scenario

you can do it using: [(:math/half-of {:n 4 :pathom/as :another-name} (:math/half-of {:n 6})]

but there is a caveat here

pathom does cache all resolver calls by default

and currently there is a problem that it doesn't consider the params in this caching, this will change in the future, but for now you have to remove cache for that to work, otherwise both calls will get the same value (because only the first will call the resolver, second will hit the cache)