Dhall: A Non-Repetitive Alternative to YAML • Hacker News Board

Re: Dhall: A Non-Repetitive Alternative to YAML

#81

Post by ff_ » Thu, Jul 04, 2019, 9:36 PM UTC

ben509 wrote: post #79

ljm wrote: post #50

Earlier quoted context omitted.

Not everybody’s a fan of C++, yet still... YAML has its detractors and many of the criticisms against it are valid. It’s ambiguous and confusing and deeply nested significant white space, with odd indentation rules and optional syntax, is incredibly hard to follow as a human.

Honestly, having wrestled with YAML, I find it's easy to write YAML and a bear to process it, in that it seems to be a "read-only" format for machines. Given some YAML file, making any kind of automated change generally nukes the formatting entirely, let alone the comments. I'm sure there are some libraries that do it right, but there seem to be far more that are just awful. One nice thing about Dhall is that there's…

Yep, we use the Haskell implementation as a library in Spago [0] and automatically migrating the configuration from old versions is a breeze as we can just manipulate the AST by pattern matching on it, e.g. see [1]

The above is quite standard in JSON/YAML too though, but an awesome thing you can do in Dhall is that - since you have functions - you can write migrations for Dhall data in Dhall itself, e.g. see [2]

[0]: https://github.com/spacchetti/spago [1]: https://github.com/spacchetti/spago/blob/a77b869edcfddd592f4... [2]: http://www.haskellforall.com/2017/11/semantic-integrity-chec...

Re: Dhall: A Non-Repetitive Alternative to YAML

#82

Post by [deleted] » Thu, Jul 04, 2019, 9:40 PM UTC

[deleted]

Re: Dhall: A Non-Repetitive Alternative to YAML

#83

Post by arkh » Thu, Jul 04, 2019, 9:45 PM UTC

   let input =
      { relative = "daughter"
      , movies   = [ "Boss Baby", "Frozen", "Moana" ]
      }

We don't frequent the same kind of "non-technical users" I guess.

Re: Dhall: A Non-Repetitive Alternative to YAML

#84

Post by desc » Thu, Jul 04, 2019, 9:53 PM UTC

Programmable configuration is always and without exception a monumentally stupid idea.

Programmatic generation of static configuration files can be very useful.

Sufficiently complex examples of the latter might as well be the former as far as maintenance is concerned.

If you need to write a program to configure your program, you're probably doing it wrong.

Re: Dhall: A Non-Repetitive Alternative to YAML

#85

Post by Ericson2314 » Thu, Jul 04, 2019, 9:53 PM UTC

zeliard wrote: post #52

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 comp…

Cue is a bit too cute trying to combine the subtyping and inhabitance relations into one.

Re: Dhall: A Non-Repetitive Alternative to YAML

#86

Post by markandrewj » Thu, Jul 04, 2019, 9:53 PM UTC

My comment isn't specifically about Dhall, but about the note on Turing completeness. I often read comments about how YAML/JSON is not turning complete. These comments normally frame the lack of Turing completeness as being a short coming of the format(s). I find this interesting because one the reasons that the industry moved away from XML was to have cleaner separation between data and logic. I generally tend to think that it is cleaner to separate logic and data, instead of creating a tight coupling. I don't read many people making comments from this perspective though. I am not trying to say we can't do better then YAML/JSON, I am just trying to offer some food for thought. I tend to view JSON/YAML as a data exchange format, and not a programming language, so I am not bothered by the lack of Turing completeness.

Re: Dhall: A Non-Repetitive Alternative to YAML

#87

Post by ape4 » Thu, Jul 04, 2019, 9:55 PM UTC

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_.

Also Relaxed JSON. http://www.relaxedjson.org/

Re: Dhall: A Non-Repetitive Alternative to YAML

#88

Post by nine_k » Thu, Jul 04, 2019, 10:03 PM UTC

markandrewj wrote: post #86

My comment isn't specifically about Dhall, but about the note on Turing completeness. I often read comments about how YAML/JSON is not turning complete. These comments normally frame the lack of Turing completeness as being a short coming of the format(s). I find this interesting because one the reasons that the industry moved away from XML was to have cleaner separation between data and logic. I generally tend to th…

Not being Turing-complete is a feature.

A Turing-complete language allows to write programs that never terminate. This is not what a config file should be capable of.

Re: Dhall: A Non-Repetitive Alternative to YAML

#89

Post by skybrian » Thu, Jul 04, 2019, 10:06 PM UTC

codebje wrote: post #76

choeger wrote: post #19

Hmm... So the authors claim that their language is guaranteed to terminate for all well-typed programs. That is actually a nice spot for configuration languages. Yet, I wonder how a) they guarantee it, as I have seen no obvious link to the language's semantics b) useful this is in practice. Nevertheless, very nice approach, indeed.

Build systems tend to get very complex Turing complete scripts, such as gradle for Java or Make for C. Having something almost as powerful but reducible to a normal form is very helpful for CASE tools.

Banning Turing completeness doesn't give you the property you want, though. Knowing that reducing to a normal form eventually terminates if you wait a million years may be something mathematicians care about, but isn't of practical use.

What matters is that you can analyze the code quickly. To find that out, one way is to try it and kill the process if it takes too long.

Or perhaps better would be to come up with a portable definition of what "takes too long" means that you can put in a presubmit check. Something like "running out of gas" in Ethereum.

Re: Dhall: A Non-Repetitive Alternative to YAML

#90

Post by amingilani » Thu, Jul 04, 2019, 10:11 PM UTC

I thought the typo in the challenge was that the keys were in the root of the user's home directory, instead of the `.ssh` directory. So, I added `.ssh/` between the key and user home directory.