In a comment on my entry on (not) using YAML for human-written configuration files, Wolfgang Richter asked what I thought of Dhall as a standard for configuration. I'm afraid that I have to rain on everyone's parade: I don't believe that any generic and general language can be used for configuration files for programs that need complex configuration (setting aside some problems with using languages, like reasoning about the result and the general lack of clarity).

Programs with complex configuration needs are almost always expressing some sort of logic about some domain (and sometimes more than one), whether this is conditional logic or description of transformations or something else. Both the logic of what can be expressed and done and the terms and elements of the domain are specific and custom to the program. This is what you see in firewall rules, whether OpenBSD PF or Linux's various generations of systems, in Exim (in SMTP ACLs, routers, and other elements), in Prometheus for recording and alert rules, label rewriting, and more, and even in Apache once you start using its full capabilities.

Pretty much by definition, a generic, general language doesn't have either the specific logic and restrictions or the specific terms and elements of the program's domain. As such you cannot express this complex configuration directly in the language. Either you embed strings or data structures representing this logic in your general language (the YAML approach) or you use the language to verbosely fake the logic and terms with things like (apparent) subroutine calls (the configuring in a real language approach). In both cases the result lacks readability, clarity, and often error checking. You clearly get the most readable and clear configuration file from a (good) custom configuration language that lets you directly express the program's logic about its domain.

(With that said, it's quite possible to create custom configuration languages that aren't very good at this. Language design is a skill and configuration files are far too often designed for the program to consume more than for people to read.)

Programmers love generality, and to some degree don't want to do language design, so I understand the eternal appeal of some universal language for program configurations. But no universal language like Dhall can be a genuinely good configuration language for a program with complex configuration needs.

(People who feel that their general configuration language of choice can be this are invited to write a moderately complicated Apache virtual host configuration (with several sets of permissions and proxying for different URLs and sub-URLs, and don't forget Let's Encrypt's HTTP authentication) or a set of OpenBSD PF rules in their language, and see how it comes out. It would make for some interesting blog posts for anyone so inclined.)