Dhall 2017 Survey (Responses)
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

 
View only
 
 
ABCDEFGHIJKLM
1
Timestamp
Which option describes how often you use Dhall:
Would anything encourage you to use Dhall more often?
What do you use Dhall for?
Why do you use Dhall?
What should Dhall development focus on?
Other feedback
2
1/1/2018 20:15:46Briefly tried it out
Mainly, a formal spec (also an ATS parsing implementation)
Getting Dhall to work with other languages
3
1/1/2018 20:34:24Use it at work
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.
4
1/1/2018 20:38:01Briefly tried it out
I would use Dhall more often if it had better type synonym support.
Ad hoc command-line tools
Ergonomics and tools for refactoring
5
1/1/2018 22:54:36Briefly tried it out
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.
6
1/1/2018 23:06:45Use it at work
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.
7
1/1/2018 23:11:57
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.
Kubernetes
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
8
1/1/2018 23:15:08Never used it
Just haven't gotten around to it yet but will probably use it for something at work instead of JSON
More of the same :)
9
1/1/2018 23:40:50Briefly tried it out
Better error messages; more concise sum types.
Config
Strong typing & schema
10
1/1/2018 23:45:43Never used itDropping the lets
11
1/1/2018 23:54:54Briefly tried it out
simpler syntax; ability to describe the whole config in one file
12
1/2/2018 0:45:26Never used it
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
/shrug
13
1/2/2018 3:50:03Briefly tried it out
More compilation outputs, e.g. Java
Common functions for compilation output, e.g. lambda lifting
Dhall is awesome!
14
1/2/2018 5:29:44Never used it
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.
15
1/2/2018 8:01:03Never used it
Stable spec, editor support, type inference
KOTGW
16
1/2/2018 8:25:34Never used itJulia bindings
17
1/2/2018 8:48:07Never used it
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.
18
1/4/2018 11:56:08Briefly tried it out
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 preprocessor
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.
19
1/6/2018 20:27:04Use it at work
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!
20
1/26/2018 13:18:11
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
Loading...
 
 
 
Form Responses 1
 
 
Main menu