Which option describes how often you use Dhall:

Would anything encourage you to use Dhall more often?

What do you use Dhall for?

What should Dhall development focus on?

Mainly, a formal spec (also an ATS parsing implementation)

Getting Dhall to work with other languages

Some way to find functions would be immensely helpful. The way to currently find functions is by word of mouth.

Backends for more languages would be great.

HTML templating, providing better manifest files (elm-package.json)

Dhall as a template language allows us to express all of the inputs to a template in one place. We don't have to hunt-and-peck to find out what a template is parameterized by. And if we want to understand what some variable is in the template, we can just look at the top of the file where its type is declared.

We want exact dependencies for our elm code. There is no specific syntax for exact versions in elm-package.json. There is a hack around that limitation which requires enforcement by convention (or CI scripts or some such). We use Dhall to generate exact versions by construction. The JSON that's generated uses the hack around the limitation, but we don't have to think about that accidental complexity.

Providing backends to other languages.

Using Dhall from Haskell is a cinch. The Haskell package makes it so you hardly notice that you're calling out to an entirely different language. It works as well as something like aeson.

Having that sort of ease of use in different languages would be a tremendous help for people wanting to use Dhall from within a different language.

I would use Dhall more often if it had better type synonym support.

Ad hoc command-line tools

Ergonomics and tools for refactoring

Verbosity for writing values in sum types was a no-go for our use case

Usability and some more ecosystem development

We tried it as an option at work for defining some APIs but describing values in sum types was way too verbose (though I think I understand why it might be needed). We really like the promise of a strongly typed config language but it was pretty much unusable for us without building other tooling to potentially improve ergonomics.

Missing a linter usable in editors for in-buffer error highlighting.

Sometimes have to work around record or Turing completeness limitations to generate desired json or yaml: often need record keys that are referenced from elsewhere as strings.

Would like to be able to compute the sha1 or similar of a file or expression.

Generating docker swarm and other configs from common templates with specific variables inserted safely.

JSON and yaml suck, want to know about errors at compile time.

You rock. Thanks for all your work for the community.

Use it for my personal projects

Better syntax for optional values. It is abysymmal now. But perhaps I'm using dhall wrong. My colleague suggests merging into default values.

Schema validation. Kubernetes is known for blowing up in your face at runtime by doing evaluation and parsing at the same time

Usability and elegance of the language. Now the syntax is sometimes a big verbose

Just haven't gotten around to it yet but will probably use it for something at work instead of JSON

Better error messages; more concise sum types.

Strong typing & schema

simpler syntax; ability to describe the whole config in one file

I worry that contributors/friends who'd like to work on a project with me would be intimidated because they don't know the lambda calculus

More compilation outputs, e.g. Java

Common functions for compilation output, e.g. lambda lifting

It's cool, but I'm yet to be convinced it will make my life easier

Formal semantics/verification

Last time I checked, I found syntax a bit awkward. Hey, Wadler's law :) Anyway, great job! I'm not using Dhall, but I try to follow its development, because it's different from everything else I've seen.

Stable spec, editor support, type inference

Rich functinality and concise syntax

Libraries for other programming languages. For example, a Rust implementation would be nice as it is arguably more straight forward to integrate with other things.

The main thing is more time on my part (adoption as JSON-preprocessor and via Haskell high on my TODO), but now that you ask, a Python binding

JSON is universal but a bit dumb

The focus on the standard, as discussed in the 2017 review, is sound.

Motivational essays such as the 'Year in review' and others on Dhall on 'Haskell for all' are great. It was these that put Dhall on my radar and marked it as something special.

Scala integration, full type inference, row polymorphism for records.

configuration - use haskell integration and spit out json/yaml on some projects (to kubernetes configs for instance)

I love pure fp and dealing with configs wastes a lot of my time and is often error prone

I am in favor of the standardization that seems to currently be a focus. I also personally would enjoy some more advanced type system features, though this seems to not be a goal if the project.

I love the project and am grateful for all the work that's been done to make it accessible and well documented. Keep up the good work!