Right now I’m brainstorming topic ideas for a Dhall Leanpub book I’m going to write that will collect “How-to” guides for various design patterns that are part of Dhall’s oral tradition but that have never been systematically documented anywhere outside of mailing lists, StackOverflow and GitHub issues.
Here are some topic ideas I have so far (in no particular order) and I also invite people to share their own ideas in this thread, too:
- What use cases is Dhall appropriate/mature for?
- How to create an ad-hoc binding to an existing YAML/JSON configuration (i.e. a one-off binding for an internal project)
- How to create a systematic binding to widely used YAML configuration format (e.g. like
dhall-kubernetes
) - How to check a Dhall configuration file against a schema (i.e. type annotations)
- How to migrate a Dhall configuration file (i.e. a Dhall function)
- How to deal with weakly-typed JSON idioms (e.g. the
JSON
type) - How to host a package for others to use (e.g. GitLab/GitHub)
- How to make a package discoverable (???)
- How to use/obtain/“install” a remote expression/package (e.g. semantic integrity check)
- How to organize a package (i.e. a typical record API)
- How to organize a project (i.e. filesystem layout and managing interdependencies)
- How to make invalid types unrepresentable (i.e. strongly-typed programming idioms)
- How to secure a Dhall project (e.g. understanding the threat model)
- How to share a Dhall configuration file across multiple languages and file
formats (e.g. variousdhall-to-*
tools and language bindings) - Common idioms (e.g. defaults record +
//
) - Naming conventions (e.g. types/alternatives are typically uppercase)
- How to integrate with twelve-factor app
- How to use tools like
dhall-to-{json,yaml}
/{json,yaml}-to-dhall
- How to integrate Dhall with CI (i.e. automatic formatting/linting/caching)
- How to edit Dhall code with IDE support
- How to cope with an evolving language standard
Also, a lot of this stuff might go obsolete if we add language features to render certain patterns unnecessary (e.g. better support for defaults, as a hypothetical example), but the book will be set up on GitHub in a way to accept pull requests to keep it up-to-date.