For starters, consider any kind of configuration that might get really repetitive. Say you're running a web server that's serving several subdomains, but almost

For starters, consider any kind of configuration that might get really repetitive. Say you're running a web server that's serving several subdomains, but almost all of them are serving static files from a pretty standard directory hierarchy. You could write out each server configuration individually, like { "servers": [ { "domain": "foo.example.com", "root": "/srv/example/foo", "port": 80, "gzip": true, ...}, { "domain": "bar.example.com", "root": "/srv/example/bar", "port": 80, "gzip": true, ...}, { "domain": "baz.mydomain.com", "root": "/srv/mydomain/baz", "port": 80, "gzip": true, ...}, ] } but in a proper programming language, that'd be kind of a code smell: it's repetitive, a bunch of fields are shared between each entry, &c &c. Well, a configuration language that adds functions would let you abstract over that repetition. (This isn't Dhall syntax, because I don't know Dhall, but rather a kind of strawman syntax.) let typical_server(domain, subdomain) = { "domain": concat(subdomain, ".", domain, ".com"), "root": concat("/srv/", domain, "/", subdomain), "port" 80, "gzip": true, ... } in { "servers": [ typical_server("example", "foo"), typical_server("example", "bar"), typical_server("mydomain", "baz"), ... ] } More than that, though, it would also let you include values in your configuration fields that are themselves functions. For example, say I'm writing an email client, and I want users to be able to define labels that allow automatic sorting of emails based on various criteria: does it contain this substring, is it from this address, does it have an attachment, &c. { "labels": [ { "name": "from_joe", "criteria": { "email_address": "joe@example.com" } ] } But this only works with simple tests. Let's say a user wants to apply a label if an email is from this address or from that address or contains certain text in the body as well as a particular attachment: I would have to add all kinds of complicated edge cases to this JSON configuration, or just throw my hands up and say that the user can't do that. But with JSON + arbitrary terminating functions, I can have my cake and eat it too, because now I can include functions as values in my configuration. A user could write something like (although again, pseudocode and not Dhall): { "labels": [ { "name": "from_joe", "criteria": fun(email) => email.addr == "joe@example.com" || email.addr == "joseph@example.com" || (email.body.contains("joseph") && is_key(email.attachments[0]) } ] } That doesn't mean you'd necessarily want this for every kind of configuration, of course! But features like this—the ability to use program-like abstraction in your configuration files as well as the ability to express arbitrary terminating functions are both interesting features that make a language like this worth considering.