4 ms·

Maybe I'm just not the target audience, but I found this intriguing yet confusing. It might benefit from an explanation of typical use cases -- what do people d

by JackC 9y ago

Maybe I'm just not the target audience, but I found this intriguing yet confusing. It might benefit from an explanation of typical use cases -- what do people do now that Dhall would be a better tool for? I read the tagline: "Dhall is a programmable configuration language that is not Turing-complete," so I figured "programmable configuration language" was a term I just wasn't familiar with, and it might bring up some typical use cases if I searched for it -- but it seems like that term was invented for Dhall. So maybe the kind of example I'm looking for is: if you're now using a non-programmable configuration language, here's what that would look like, and here's the improvement if you switch to Dhall. Or if you're now using a programmable configuration language that is Turing complete, here's what that would look like, and here's the improvement if you switch to Dhall. (A more specific question: in what kind of scenarios is JSON+arbitrary terminating functions useful?)

TeMPOraL 9y ago
It's less about "programmable", it's more about "Turing-complete". Why this is important - see my other comment here for details: https://news.ycombinator.com/item?id=15190110 https://news.ycombinator.com/item?id=15190110. TL;DR: langsec.
nathancahill 9y ago
More commonly called a DSL. See: Varnish's configuration language, which is also not Turing-complete: https://varnish-cache.org/docs/3.0/tutorial/vcl.html https://varnish-cache.org/docs/3.0/tutorial/vcl.html
kreetx 9y ago
I agree with you there, but those of you already reading this, here's what it means (what I think it means anyway ;-): Dhall is like a templating language, but statically typed and will always terminate. Typing is good because your configuration will always have correct structure -- the language itself allows you to verify this; and non-determination is good because you don't have to worry about your program accidentally not terminating. JSON, YAML, .ini, etc etc are non-programmable configuration languages, and, I guess, m4 would be an example of a Touring complete one.
KirinDave 9y ago
I use Dhall extensively now. In fact, all my typescript programs for my current employer use JSON configuration that Dhall generates (and I've tried so many times to get this to frontpage on YC, I guess I'm just not good at timing). Dhall's draw as a configuration language is that it allows you to express logic in your configuration and even call out to remote services and file handles safely. People have a gut negative reaction to this phrase even as they essentially encode non-trivial logic directly into their Chef, CircleCI, Docker-Compose and Kubernetes configs, so it's hardly a new idea. Dhall lets you write logic into your configs that otherwise would be implicit. As an example, you might define a new configuration environment with Dhall and use the types to make sure you NEVER provide production credentials, or even shared credentials. Dhall also allows you to safely call out to web services (with authentication and SSL, of course) to fill in holes or even provide non-trivial logic (it's perfectly valid to move functions around in dhall over the wire). I use this feature to map a tiny microservice that resolves Hashicorp Vault calls to AWS credentials just-in-time as I ship, and I feel very confident that it's safe because I can encode the sorts of permissions and their resolution directly into the types I'm handling. You could start using Dhall instead of JSON today for configs, and the main advantage is that you can assert values have specific types (and also provide sane loops over list fields). Dhall is actually a pretty amazing invention and I keep trying to work up the guts and time to write a typescript interpreter for it.
- kobeya 9y ago
  You've also failed to link to it here.
  - deleted 9y ago
    [deleted]
- nathancahill 9y ago
  Interesting, can you share the link you were submitting? I looked through your submissions but didn't see it.
andolanra 9y ago
For starters, consider any kind of configuration that might get really repetitive. Say you're running a web server that's serving several subdomains, but almost all of them are serving static files from a pretty standard directory hierarchy. You could write out each server configuration individually, like { "servers": [ { "domain": "foo.example.com", "root": "/srv/example/foo", "port": 80, "gzip": true, ...}, { "domain": "bar.example.com", "root": "/srv/example/bar", "port": 80, "gzip": true, ...}, { "domain": "baz.mydomain.com", "root": "/srv/mydomain/baz", "port": 80, "gzip": true, ...}, ] } but in a proper programming language, that'd be kind of a code smell: it's repetitive, a bunch of fields are shared between each entry, &c &c. Well, a configuration language that adds functions would let you abstract over that repetition. (This isn't Dhall syntax, because I don't know Dhall, but rather a kind of strawman syntax.) let typical_server(domain, subdomain) = { "domain": concat(subdomain, ".", domain, ".com"), "root": concat("/srv/", domain, "/", subdomain), "port" 80, "gzip": true, ... } in { "servers": [ typical_server("example", "foo"), typical_server("example", "bar"), typical_server("mydomain", "baz"), ... ] } More than that, though, it would also let you include values in your configuration fields that are themselves functions. For example, say I'm writing an email client, and I want users to be able to define labels that allow automatic sorting of emails based on various criteria: does it contain this substring, is it from this address, does it have an attachment, &c. { "labels": [ { "name": "from_joe", "criteria": { "email_address": "joe@example.com" } ] } But this only works with simple tests. Let's say a user wants to apply a label if an email is from this address or from that address or contains certain text in the body as well as a particular attachment: I would have to add all kinds of complicated edge cases to this JSON configuration, or just throw my hands up and say that the user can't do that. But with JSON + arbitrary terminating functions, I can have my cake and eat it too, because now I can include functions as values in my configuration. A user could write something like (although again, pseudocode and not Dhall): { "labels": [ { "name": "from_joe", "criteria": fun(email) => email.addr == "joe@example.com" || email.addr == "joseph@example.com" || (email.body.contains("joseph") && is_key(email.attachments[0]) } ] } That doesn't mean you'd necessarily want this for every kind of configuration, of course! But features like this—the ability to use program-like abstraction in your configuration files as well as the ability to express arbitrary terminating functions are both interesting features that make a language like this worth considering.
Gabriel439 9y ago
Author here: there is a reason why "programmable configuration language" is a fairly new term. Most of the time, when people want a programmable configuration they use whatever language they are already programming in. So, for example, if you are writing a program in Scala you might write the program's configuration in Scala, too. For example, this is how Scala's SBT works: the SBT configuration is written in Scala However, there are some down-sides with writing your configuration within a language like Scala (or any other mainstream language). For example, your program "configuration" can hang, crash, throw exceptions, or destroy your system if it is running with sufficiently elevated privileges. Dhall has none of those problems. Similarly, you can go overboard and use excessive abstraction in other languages, which is inappropriate for a configuration file (which needs to be easy to read and understand). Dhall also avoids this issue by supporting automatic simplification of configuration files to remove abstraction, imports, and indirection (which is made possible by the fact that Dhall is not Turing complete) I'll try to rework the documentation to answer this sort of question better and also incorporate some of the other excellent replies to your question

by JackC 9y ago

TeMPOraL 9y ago

It's less about "programmable", it's more about "Turing-complete". Why this is important - see my other comment here for details: https://news.ycombinator.com/item?id=15190110 https://news.ycombinator.com/item?id=15190110. TL;DR: langsec.

nathancahill 9y ago

More commonly called a DSL. See: Varnish's configuration language, which is also not Turing-complete: https://varnish-cache.org/docs/3.0/tutorial/vcl.html https://varnish-cache.org/docs/3.0/tutorial/vcl.html

kreetx 9y ago

I agree with you there, but those of you already reading this, here's what it means (what I think it means anyway ;-): Dhall is like a templating language, but statically typed and will always terminate. Typing is good because your configuration will always have correct structure -- the language itself allows you to verify this; and non-determination is good because you don't have to worry about your program accidentally not terminating. JSON, YAML, .ini, etc etc are non-programmable configuration languages, and, I guess, m4 would be an example of a Touring complete one.

KirinDave 9y ago

I use Dhall extensively now. In fact, all my typescript programs for my current employer use JSON configuration that Dhall generates (and I've tried so many times to get this to frontpage on YC, I guess I'm just not good at timing). Dhall's draw as a configuration language is that it allows you to express logic in your configuration and even call out to remote services and file handles safely. People have a gut negative reaction to this phrase even as they essentially encode non-trivial logic directly into their Chef, CircleCI, Docker-Compose and Kubernetes configs, so it's hardly a new idea. Dhall lets you write logic into your configs that otherwise would be implicit. As an example, you might define a new configuration environment with Dhall and use the types to make sure you NEVER provide production credentials, or even shared credentials. Dhall also allows you to safely call out to web services (with authentication and SSL, of course) to fill in holes or even provide non-trivial logic (it's perfectly valid to move functions around in dhall over the wire). I use this feature to map a tiny microservice that resolves Hashicorp Vault calls to AWS credentials just-in-time as I ship, and I feel very confident that it's safe because I can encode the sorts of permissions and their resolution directly into the types I'm handling. You could start using Dhall instead of JSON today for configs, and the main advantage is that you can assert values have specific types (and also provide sane loops over list fields). Dhall is actually a pretty amazing invention and I keep trying to work up the guts and time to write a typescript interpreter for it.

kobeya 9y ago
You've also failed to link to it here.
- deleted 9y ago
  [deleted]
nathancahill 9y ago
Interesting, can you share the link you were submitting? I looked through your submissions but didn't see it.

andolanra 9y ago

For starters, consider any kind of configuration that might get really repetitive. Say you're running a web server that's serving several subdomains, but almost all of them are serving static files from a pretty standard directory hierarchy. You could write out each server configuration individually, like { "servers": [ { "domain": "foo.example.com", "root": "/srv/example/foo", "port": 80, "gzip": true, ...}, { "domain": "bar.example.com", "root": "/srv/example/bar", "port": 80, "gzip": true, ...}, { "domain": "baz.mydomain.com", "root": "/srv/mydomain/baz", "port": 80, "gzip": true, ...}, ] } but in a proper programming language, that'd be kind of a code smell: it's repetitive, a bunch of fields are shared between each entry, &c &c. Well, a configuration language that adds functions would let you abstract over that repetition. (This isn't Dhall syntax, because I don't know Dhall, but rather a kind of strawman syntax.) let typical_server(domain, subdomain) = { "domain": concat(subdomain, ".", domain, ".com"), "root": concat("/srv/", domain, "/", subdomain), "port" 80, "gzip": true, ... } in { "servers": [ typical_server("example", "foo"), typical_server("example", "bar"), typical_server("mydomain", "baz"), ... ] } More than that, though, it would also let you include values in your configuration fields that are themselves functions. For example, say I'm writing an email client, and I want users to be able to define labels that allow automatic sorting of emails based on various criteria: does it contain this substring, is it from this address, does it have an attachment, &c. { "labels": [ { "name": "from_joe", "criteria": { "email_address": "joe@example.com" } ] } But this only works with simple tests. Let's say a user wants to apply a label if an email is from this address or from that address or contains certain text in the body as well as a particular attachment: I would have to add all kinds of complicated edge cases to this JSON configuration, or just throw my hands up and say that the user can't do that. But with JSON + arbitrary terminating functions, I can have my cake and eat it too, because now I can include functions as values in my configuration. A user could write something like (although again, pseudocode and not Dhall): { "labels": [ { "name": "from_joe", "criteria": fun(email) => email.addr == "joe@example.com" || email.addr == "joseph@example.com" || (email.body.contains("joseph") && is_key(email.attachments[0]) } ] } That doesn't mean you'd necessarily want this for every kind of configuration, of course! But features like this—the ability to use program-like abstraction in your configuration files as well as the ability to express arbitrary terminating functions are both interesting features that make a language like this worth considering.

Gabriel439 9y ago

Author here: there is a reason why "programmable configuration language" is a fairly new term. Most of the time, when people want a programmable configuration they use whatever language they are already programming in. So, for example, if you are writing a program in Scala you might write the program's configuration in Scala, too. For example, this is how Scala's SBT works: the SBT configuration is written in Scala However, there are some down-sides with writing your configuration within a language like Scala (or any other mainstream language). For example, your program "configuration" can hang, crash, throw exceptions, or destroy your system if it is running with sufficiently elevated privileges. Dhall has none of those problems. Similarly, you can go overboard and use excessive abstraction in other languages, which is inappropriate for a configuration file (which needs to be easy to read and understand). Dhall also avoids this issue by supporting automatic simplification of configuration files to remove abstraction, imports, and indirection (which is made possible by the fact that Dhall is not Turing complete) I'll try to rework the documentation to answer this sort of question better and also incorporate some of the other excellent replies to your question