amarrella/dhall-lang

Maintainable configuration files

Dhall is a programmable configuration language that provides a non-repetitive alternative to YAML.

You can think of Dhall as: JSON + functions + types + imports

Note that while Dhall is programmable, Dhall is not Turing-complete. Many of Dhall's features take advantage of this restriction to provide stronger safety guarantees and more powerful tooling.

You can try the language live in your browser by visiting the official website:

• https://dhall-lang.org

Getting started

The easiest way to get started experimenting with Dhall is to install the dhall-to-json and/or dhall-to-yaml executables, which enable you to generate JSON and YAML, respectively, on the command line. Platform- and runtime-specific installation instructions can be found in the Dhall wiki.

For other ways to integrate Dhall in your project, read:

• How to integrate Dhall

Tutorials

For a short introduction, read:

• Learn Dhall in Y minutes

To learn more about core language features, read:

• Core language features

For an even longer hands-on tutorial, read:

• Getting started: Generate JSON or YAML

Features:

• Total - Evaluation always terminates and never hangs or infinitely loops
• Safe - Evaluation never crashes or throws exceptions
• Distributed - Expressions can reference other expressions by URL or path
• Strongly normalizing - All expressions (even functions) have a normal form
• Statically typed - Configurations can be validated ahead-of-time
• Strongly typed - No coercions, casts or subtyping
• Built-in data types - Includes lists, anonymous records and anonymous unions

Documentation

The Dhall language originated as a Haskell-specific configuration file format and is expanding to support more languages and file formats. Consequently, the Haskell package for Dhall still hosts the official tutorial and language manual:

• Dhall tutorial and manual

... which will eventually become a language-agnostic tutorial

You can also read about the original motivation behind the language here:

• Dhall - A non-Turing-complete configuration language

Finally, we have a cheatsheet for a very condensed overview and quick lookup:

• Dhall Cheatsheet

Standard Library

Dhall's Standard Library is called Prelude. It implements various utilities to work with the builtin types. Where to find it:

• Official link - https://prelude.dhall-lang.org
• Github repo
• Nix: both dhall and dhall.prelude derivations are built, install the Prelude with e.g. nix-env -iA nixpkgs.dhall.prelude

Development status

The current version and versioning policy is detailed in the Versioning document, and you can see the latest changes in the Changelog.

There is an effort under way to formalize the language semantics for Dhall, to help with porting it to other languages. If you would like to assist with either standardizing the language or creating new bindings just open a new issue or contribute to existing ones in the issue tracker.

Design philosophy

Programming languages are all about design tradeoffs and the Dhall language uses the following guiding principles (in order of descending priority) that help navigate those tradeoffs:

• Polish

  The language should delight users. Error messages should be fantastic, execution should be snappy, documentation should be excellent, and everything should "just work".

• Simplicity

  When in doubt, cut it out. Every configuration language needs bindings to multiple programming languages, and the more complex the configuration language the more difficult to create new bindings. Let the host language that you bind to compensate for any missing features from Dhall.

• Beginner-friendliness

  Dhall needs to be a language that anybody can learn in a day and debug with little to no assistance from others. Otherwise people can't recommend Dhall to their team with confidence.

• Robustness

  A configuration language needs to be rock solid. The last thing a person wants to debug is their configuration file. The language should never hang or crash. Ever.

• Consistency

  There should only be one way to do something. Users should be able to instantly discern whether or not something is possible within the Dhall language or not.

The Dhall configuration language is also designed to negate many of the common objections to programmable configuration files, such as:

"Config files shouldn't be Turing complete"

Dhall is not Turing-complete. Evaluation always terminates, no exceptions

"Configuration languages become unreadable due to abstraction and indirection"

Every Dhall configuration file can be reduced to a normal form which eliminates all abstraction and indirection

"Users will go crazy with syntax and user-defined constructs"

Dhall is a very minimal programming language. For example: you cannot even compare strings for equality. The language also forbids many other common operations in order to force users to keep things simple

The biggest issue with using Dhall as a configuration language is that there are currently only Haskell bindings. If you would like to contribute bindings to another language then go for it, otherwise I will do my best to contribute them as time permits.

Name

The language is named after a Dustman from the game Planescape: Torment who belongs to a faction obsessed with death (termination). The logo represents his quill and inkwell

The name rhymes with "tall"/"call"/"hall" (i.e. "dɔl" for a US speaker or "dɔːl" for a UK speaker using the International Phonetic Alphabet).

Contributors

Code Contributors

This project exists thanks to all the people who contribute. [Contribute].

Financial Contributors

Become a financial contributor and help us sustain our community. [Contribute]

Individuals

Organizations

Support this project with your organization. Your logo will show up here with a link to your website. [Contribute]