In the Creating you own bindings section of the docs you mention Template Haskell as an alternative to codegen.
I don’t know anything about Template Haskell (yet) but I became interested.
Since we know that Daml is based on Haskell, this connection raises the question for me: did you create Daml using Template Haskell in the first place?
We do use TemplateHaskell in our code base if that’s what you’re asking. However, we use it very sparingly. From a quick look at our codebase and my own memory, we only use it for generating lenses in a few places (and we use lenses sparingly as well) which is only a handful of places across the whole codebase.
Personally, I’m not a huge fan of TemplateHaskell. It leads to slow compilation times, it breaks cross-compilation, it leads to a nightmare of linker errors in any reasonably complicated setup & it is often quite hard to understand.
If you are looking to build Haskell bindings for Daml, I’d recommend to go the codegen route using something like gRPC-haskell.
Thanks, will check it out
The original discussion that produced the linked docs should be illuminating.
To expand on that, I would give a different recommendation from @cocreature: if you’re building a codegen for some language, figure out what parts the language’s metaprogramming features are good at, and what parts code-generation is better at, and build accordingly.
For example, the Scala codegen is such a hybrid: generating code for some tasks, using simple features to avoid generating code for other tasks (e.g. avoiding generating static methods with TemplateCompanion), and using language-specific metaprogramming to avoid generating code for yet other tasks (e.g. API value encoding and create/exercise typeclasses).
That’s really interesting, I will check out the discussions connected to other parts of the docs too.