Dhall: A Non-Repetitive Alternative to YAML
61–70 of 181 posts
Re: Dhall: A Non-Repetitive Alternative to YAML
#62Re: Dhall: A Non-Repetitive Alternative to YAML
#63If you have functions that can call functions, you'd better not have recursion if you want to not be Turing-complete. Non-Turing-completeness is certainly very important in many cases (e.g., in DTrace and eBPF), but I'm not sure that it's so important for configuration . Assuming for a moment that I don't need non-Turing-completeness for configuration, my choice of DSL would be jq[0]! Using jq for configuration means…
So you could describe e.g. a cluster of machines entirely in Dhall and derive Ansible YAML scripts (with all their boilerplate), derive DNS config files, etc. etc. all from a single strongly typed description.
Re: Dhall: A Non-Repetitive Alternative to YAML
#64If you have functions that can call functions, you'd better not have recursion if you want to not be Turing-complete. Non-Turing-completeness is certainly very important in many cases (e.g., in DTrace and eBPF), but I'm not sure that it's so important for configuration . Assuming for a moment that I don't need non-Turing-completeness for configuration, my choice of DSL would be jq[0]! Using jq for configuration means…
One valuable point of Dhall is that it is programmable (yet not TC) in such a way to that you can e.g. describe a whole system entirely in Dhall and then (in Dhall!) derive whatever further configurations (plural!) you need from that. This is much more feasible than in e.g. YAML because Dhall is strongly typed. So you could describe e.g. a cluster of machines entirely in Dhall and derive Ansible YAML scripts (with al…
Re: Dhall: A Non-Repetitive Alternative to YAML
#65This looks very useful.
looking further, it seems that aside from repetitiveness, safety is the main focus: https://github.com/dhall-lang/dhall-lang/wiki/Safety-guarant... which in Rust, we're solving this via SANE and SCL: https://gitlab.com/bloom42/sane-rs https://github.com/keats/scl I'm not sure how much need there is for an additional programming layer, especially within config (the part of a program with the simplest syntactic require…
- functions
- a powerful typesystem
- remote (HTTP) imports with sha256 checksums
Re: Dhall: A Non-Repetitive Alternative to YAML
#66Earlier quoted context omitted.
It's not even in the same solution space. I can't replace my YAML with Dhall and consume it directly. I have to now depend on the converter to go from Dhall -> YAML/JSON. All I did was add another layer of complexity into my config. Maybe you'll benefit from the added abstraction; I see the value in having "typed" configs that are semi-scriptable but not turing complete. But it's in no way a "replacement".
>> I can't replace my YAML with Dhall and consume it directly. Sorry I don't get it. Why not? Because your favorite languages do not support it?
Re: Dhall: A Non-Repetitive Alternative to YAML
#67Earlier quoted context omitted.
I don't get why you'd build a language in 2019 which disallows a trailing comma in lists.
Yep. The solution to comma issues isn't to put every single one in a place nobody usually puts them - it's to be more forgiving about allowing the occasional trailing one.
Re: Dhall: A Non-Repetitive Alternative to YAML
#68Earlier quoted context omitted.
Yeah, because that's what most configuration languages differ in.
And yet, in focusing on the syntax, you missed the biggest difference between Dhall and other configuration languages: safe, termination-guaranteed non-Turing-complete computation.
Re: Dhall: A Non-Repetitive Alternative to YAML
#69Earlier quoted context omitted.
>> I can't replace my YAML with Dhall and consume it directly. Sorry I don't get it. Why not? Because your favorite languages do not support it?
How many languages have an Dhall implementation? One?