Dhall-lang: Motivation for Dhall over Haskell?

[saurabhnanda]

I'm about to write a massive JSON config file to describe my DB schema, which will be used by a script, to generate Haskell <=> DB boilerplate code.

I read https://github.com/dhall-lang/dhall-lang/wiki/Programmable-configuration-files to understand if Dhall is right tool for the job, but I'm confused at the end. If one of the main motivation for Dhall is to be configurable, in what scenario would one prefer it over plain ol' Haskell? Why write Dhall expressions only to expose them as Haskell records, when one can write Haskell records directly?

[ocharles]

1. Dhall is not Turing complete - your configuration files are guaranteed to terminate and cannot throw exceptions.
2. Dhall is a simpler language
3. Dhall has file imports as an expression, which can make it easier to compose configurations and re-use things.

Essentially the arguments for using Dhall are the same arguments you'd use for JSON, but Dhall is a better JSON because it's typed, supports code re-use, and has support for functions.

You could also use the same arguments for using something like Lua as a scripting language - it's lightweight and means you can build a core engine for your application, and then push scripting out of the application to work in a simpler domain and avoid huge recompilation.

It's also much easier to use Dhall than to use the GHC API, in the sense of actually consuming configuration files. If you want to deploy applications with configuration files, if those configuration files are Haskell source that have to be parsed & linked at runtime, that is considerably harder than simply using input from dhall.

[saurabhnanda]

Essentially the arguments for using Dhall are the same arguments you'd use for JSON, but Dhall is a better JSON because it's typed, supports code re-use, and has support for functions.

So, assuming that someone is looking for something better than JSON/YAML for a complex config file, this would not be the right comparison to make, yes? A better comparison would be -- general purpose programming language (like Haskell) vs simplified programming language (i.e. Dhall), right?

It's also much easier to use Dhall than to use the GHC API, in the sense of actually consuming configuration files. If you want to deploy applications with configuration files, if those configuration files are Haskell source that have to be parsed & linked at runtime, that is considerably harder than simply using input from dhall.

In the Haskell vs Dhall debate, this is a stronger argument. So, the question for my use-case boils down to -- do I want to recompile my code-gen script every time the config file changes?

[Gabriel439]

@saurabhnanda: You should read this:

https://github.com/dhall-lang/dhall-lang/wiki/Safety-guarantees

Also, Dhall has some features that Haskell does not, such as:

• Anonymous records
• Strong normalization
• Code as data (you can transmit Dhall functions and types over the network unlike Haskell types and functions)

... and as you just mentioned you don't need to recompile your program to change it

[ocharles]

@saurabhnanda did this answer your question?