Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dhall: A Non-Repetitive Alternative to YAML

dhall-lang.org

Post reply on HN
Print view View original

51–60 of 181 posts

Re: Dhall: A Non-Repetitive Alternative to YAML

#51

Post by epage »

adev_ wrote: post #28

For a pragmatic, really readable configuration file format, TOML never disappointed me ( https://github.com/toml-lang/toml#user-content-local-date ). - This is human readable contrary to the JSON family and its {} abuses. - It is not space / ident base contrary to YAML that becomes very quickly a mess to write and a mess to parse.

As a fan of TOML, I want to be clear on the downsides.

TOML is good for data layed out with TOML. Representing arbitrary nested arrays and tables gets messy.

Also, the constraint on homogenous shallow types has impacted me in some cases. Originally, I was all on board. Arrays should be homogenous. The problem is logically homogenous vs syntactically homogenous.

Cargo uses tables to declare dependencies. The values are logically homogenous, they are declarations. Synatictically, some values are strings while the rest are sub-tables. The string is just shorthand for a table though.

This feature can't be implemented in arrays like it can with tables.

Re: Dhall: A Non-Repetitive Alternative to YAML

#52

Post by zeliard »

Couple of contenders:

- Jsonnet (https://jsonnet.org/) - simpler syntax and less concepts to learn, just an extension of JSON. But no type checking. An open source offspring of Google's internal config language (GCL/BCL)

- Cue (https://github.com/cuelang/cue) - a more ambitious attempt to fix GCL/BCL by replacing inheritance as the fundamental compositional primitive with constraint unification.

Great thread comparing them against each other by the authors of both: https://github.com/cuelang/cue/issues/33

Cue seems kind of similar to Dhall on first sight, but I haven't used either enough for an informed opinion yet.

Re: Dhall: A Non-Repetitive Alternative to YAML

#53

Post by epage »

NuSkooler wrote: post #8

Still much prefer HJSON ( http://hjson.org/ ) for stuff that people might need to touch. If it's truly for end-users (read: non-admin/dev types), you probably shouldn't have them touching configuration files _at all_.

Don't fully remember why I prefer json5 to hjson but at a quick glance, bare values is one. Bare values are ripe for someone entering in a string and accidentally getting a bool or number instead.

Re: Dhall: A Non-Repetitive Alternative to YAML

#54

Post by StreamBright »

dymk wrote: post #38
Vosporos wrote: post #24

Earlier quoted context omitted.

So? They live in the same solution domain for the same problem. Moreover, Dhall can generate (typechecked) YAML and JSON.

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

#55

Post by nikolay »

mcaruso wrote: post #43
nikolay wrote: post #15

Earlier quoted context omitted.

Yeah, but how is this relevant? YAML, for example, makes JSON a subset, which lets it consume existing JSON without any need for conversion. It's easy to learn, and readable. Leading commas are eyesores. Plus, not everybody is a fan of ML! These are not mass market languages.

Seems like you're criticizing it just because it's different from what you're used to.

Yeah, it deviates from the norm and the expectations of most people, most of who are not even developers - lots of BAs today configure apps via such files.

Re: Dhall: A Non-Repetitive Alternative to YAML

#56

Post by zeliard »

isoprophlex wrote: post #13

To me, worrying about config files seems like the ultimate exercise in bikeshedding. You either need a simple list of items (eg. dependencies) or key/value pairs. Use a text file or yml or json or whatever. Or you need templating, the use of functions, etc, like dhall provides. But then, why not use the language you're already using for the rest of your project, or a bash script to export some variables? Might sound…

>But then, why not use the language you're already using for the rest of your project, or a bash script to export some variables?

Well, for same reason, say, why people would use a javascript framework to build a webapp over vanilla js. Both could do the job, and for simple cases there's little reason to go with a framework resp. specialized config language.

But as your app/config gets larger and more complex, using a framework resp. config language would tend to get the job done more efficiently by providing you structure and toolbox with solutions to common pain points.

Config generators themselves tend to be a rather heavyweight all-or-nothing solution which leads people to compromise on some adhoc middle-ground solutions like YAML with jinja templates with unclear evaluation semantics. A good config language designed from the ground up can be so much better than this unholy yaml/jinja mess!

Finally, one of the key selling points of specifically Dhall is type checking. Implementing that in config generators in a generic untyped scripting language would be a nontrivial amount of boilerplate, and boilerplate elimination is what config languages are all about.

Re: Dhall: A Non-Repetitive Alternative to YAML

#57

Post by kccqzy »

nikolay wrote: post #21
tobr wrote: post #14

So far, only comments complaining about syntax. You can do better, HN!

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

#58

Post by mitchtbaum »

mitchtbaum wrote: post #40

This 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 requirements).

for my projects where "ahead-of-time validation" is needed, we're currently using SCL's parser for safety guarantees:

https://github.com/foundpatterns/contentdb

https://github.com/foundpatterns/lighttouch/blob/d7ada4576a6...

https://github.com/foundpatterns/torchbear/blob/4dd2b9ea76ba...

Re: Dhall: A Non-Repetitive Alternative to YAML

#59

Post by hk__2 »

mcaruso wrote: post #43
nikolay wrote: post #15

Earlier quoted context omitted.

Yeah, but how is this relevant? YAML, for example, makes JSON a subset, which lets it consume existing JSON without any need for conversion. It's easy to learn, and readable. Leading commas are eyesores. Plus, not everybody is a fan of ML! These are not mass market languages.

Seems like you're criticizing it just because it's different from what you're used to.

> Seems like you're criticizing it just because it's different from what you're used to.

This is a valid criticism. There are already widely-used data formats; if you do something different it should be justified.

Re: Dhall: A Non-Repetitive Alternative to YAML

#60

Post by cryptonector »

If 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 that I can use JSON, TOML-style, and other ways of expressing complex data, including combinations of them, all with "interpolation" (not quite) and complex computation being available.

  [0] https://stedolan.github.io/jq/
Post reply on HN