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?
1 Like
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.
1 Like
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).
1 Like
That’s really interesting, I will check out the discussions connected to other parts of the docs too.