Hi there,
We’re scoping out the idea of leveraging Dhall to host ‘data type specifications’. If you’re familiar with schema systems such as Google Protobufs, JSON Schemas, CDDL or anything of this sort, that’s what we’re trying to build.
More precisely, imagine taking out Haskell ADTs and putting them in a configuration file, such that a dedicated complier+codegen pipeline can create type libraries for a variety of target languages.
We want to leverage an existing configuration language environment, and Dhall seems like a great fit. Not only does one get functions to manage reuse, automation and tooling that comes with Dhall (lsp, formatters) but also a fabulous way to distribute and share Dhall based configurations and specs.
Which brings me to my question…
We’re not entirely sure if having an eDSL hosted in Dhall (like dhall-kubernetes and friends) to represent our ADTs (with additional features like annotations, constraints, opaque types etc.) is appropriate. For example, in such and eDSL one would write something like the following in Dhall for the Set and Maybe types:
let defs = [
opaque "Set" ["a"],
data "Maybe" [ "a" ] (toMap { Nothing = nullary, Just = var "a" })
]
let instances = [
isJson [isJson "a"] "Maybe" ["a"]
]
Alternatively, we’re considering using Dhall natively and thinkering with the idea of using the builtin Dhall type semantics and working directly with that. Concretely, a Dhall record maps to whatever a native ‘record’ is in the target language, the same for Dhall sum types and other relevant builtins. Seems like this approach gives us existing mappings and codegen that Dhall supports for popular languages. Not to mention you don’t have the annoying verbosity that comes with eDSLs. However, my concern is that ‘data type language’ features are then very much bounded to Dhall type features.
I hope this makes sense and thank you for your time.
Cheers,
Drazen