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

161–170 of 181 posts

Re: Dhall: A Non-Repetitive Alternative to YAML

#161

Post by GordonS »

KirinDave wrote: post #152
GordonS wrote: post #135

Earlier quoted context omitted.

I did, and it's bad form to suggest otherwise. I was asking about your personal opinion, since you said it was great but didn't give any info as to why .

> I did, and it's bad form to suggest otherwise. If you say so. But... I said I think the features are good and you ask "why?" I could relist the features, but that's a waste of time. As I said, I think the combination is a good combination. In a world where people try to encode loops in YAML or JSON, even small improvements are better and Dhall is a large improvement. > I was asking about your personal opinion, sinc…

Then I apologise; because you posted I assumed you were happy to or wanted to engage in discourse, maybe highlight your favourite features, possibly debate the value it bring, that kind of thing, but I see my mistake now.

Re: Dhall: A Non-Repetitive Alternative to YAML

#162

Post by cryptonector »

Quekid5 wrote: post #160
cryptonector wrote: post #156

Earlier quoted context omitted.

I never have to "stitch together multiple invocations of jq using pipes". There was a time when I did have to, but that was years ago, and it now has the features needed to avoid that. Not sure what the point about typing was -- you can do the same derivation of data from a master entity with or without strong typing (though my preference is always for strong typing, which jq lacks).

> you can do the same derivation of data from a master entity with or without strong typing (though my preference is always for strong typing, which jq lacks). Yes, of course you can. The point is that the strong typing helps prevent inadvertent and hard-to-spot mistakes. In jq even simple typos of a field name can lead to "empty result set" silent failures instead of "what do you mean!" loud failures. That's a big t…

Strong typing generally doesn't speak to "how many values this expression should produce", only their types. Not saying it couldn't, but that even in Haskell you don't quite get that.

Re: Dhall: A Non-Repetitive Alternative to YAML

#163

Post by Quekid5 »

cryptonector wrote: post #162
Quekid5 wrote: post #160

Earlier quoted context omitted.

> you can do the same derivation of data from a master entity with or without strong typing (though my preference is always for strong typing, which jq lacks). Yes, of course you can. The point is that the strong typing helps prevent inadvertent and hard-to-spot mistakes. In jq even simple typos of a field name can lead to "empty result set" silent failures instead of "what do you mean!" loud failures. That's a big t…

Strong typing generally doesn't speak to "how many values this expression should produce", only their types. Not saying it couldn't, but that even in Haskell you don't quite get that.

I was talking about a mismatched field name. What case are you talking about?

EDIT: Actually, responding to

> Strong typing generally doesn't speak to "how many values this expression should produce"

Have you heard of affine/linear types?

Re: Dhall: A Non-Repetitive Alternative to YAML

#164

Post by eridius »

hjk05 wrote: post #157
eridius wrote: post #136

Earlier quoted context omitted.

Dhall is also a JSON generator. And you could write your own Dhall implementation that lets you consume it directly from an application if you want to, it's just nobody's considered that worth doing.

Which is odd because tons of applications in the wild already have this amazing capability of directly consuming python and Haskell without first converting to yaml. But of cause you still have the ability to both produce and consume yaml if that’s needed for some reason.

What applications directly consume Haskell code? The only examples I can think of off the top of my head are apps written in Haskell that actually get recompiled any time you change the "configuration" Haskell code.

As for Python, that's because the Python interpreter can be embedded in an app.

That said, Dhall is exposed as a Haskell library, so if you're writing a Haskell app you could consume Dhall directly and skip the YAML. https://hackage.haskell.org/package/dhall-1.24.0/docs/Dhall-... shows examples of this.

Re: Dhall: A Non-Repetitive Alternative to YAML

#165

Post by singpolyma3 »

oalessandr wrote: post #73

I'm trying to use it for Kubernetes since it can both work like helm (paramerizing functions) and kustomize (using the merge // operator). Moreover it has (safe) imports which make defining constants quite easy. There are already kubernetes bindings available https://github.com/dhall-lang/dhall-kubernetes . The syntax in the examples looks a bit more verbose and less readable than yaml but I think building sensible a…

Yeah, the formatting the `dhall` CLI tool uses isn't my favourite. Though luckily I don't usually have to look at it much :)

Re: Dhall: A Non-Repetitive Alternative to YAML

#166

Post by singpolyma3 »

hjk05 wrote: post #126

This isn’t an alternative to yaml. It’s a yaml generator. To me it’s not competing with yaml it’s competing with python or Haskell, and i’d argue that putting yet another language in your stack just for generating config files is added unneeded complexity. And sure while both python and Haskell are Turing complete, how often do we actually run into issues when generations flat config files? I mean I’ve never had that…

There is a tool to generate YAML from Dhall, but there are also language bindings for Ruby, JVM, and Haskell with more on the way. I don't think generating YAML will be a main use case for long.

Re: Dhall: A Non-Repetitive Alternative to YAML

#167

Post by singpolyma3 »

HelloNurse wrote: post #133
eridius wrote: post #129

Earlier quoted context omitted.

That's kind of like saying C isn't an alternative to assembly, it's an assembly generator.

On a practical level, C is an alternative to assembly because the appropriate black-box tools and combinations of tools allow the user to easily turn source code in either Language or a combination of both into an executable. Generating assembly from C is an implementation detail, and many C compilers don't do that. On the other hand, Dhall really is a YAML generator: the available tools allow only one-way conversion…

> in particular, there is no interpreter/library to ingest Dhall from the configured application itself

Not true. Perhaps this needs to be highlighted more prominently on the homepage. There are directly language bindings for Ruby, Haskell, and the JVM with more on the way.

Re: Dhall: A Non-Repetitive Alternative to YAML

#168

Post by singpolyma3 »

nightkoder wrote: post #69
dymk wrote: post #66

Earlier quoted context omitted.

How many languages have an Dhall implementation? One?

As far as I know Clojure, Haskell, Ruby, Rust in various stages of completion..

Both Clojure and Eta bindings should allow really anything on the JVM to consume directly.

Re: Dhall: A Non-Repetitive Alternative to YAML

#169

Post by singpolyma3 »

anentropic wrote: post #150
Jeff_Brown wrote: post #46

Earlier quoted context omitted.

> commas at the start of lines are not a requirement.

OTOH I would guess it doesn't allow a trailing comma (same problem as JSON...) so you end up with weird ugly formatting conventions

Final trailing comma is not in the standard yet, but will be soon

Re: Dhall: A Non-Repetitive Alternative to YAML

#170

Post by Gabriel439 »

bvaldivielso wrote: post #39
piotrkubisa wrote: post #27

Earlier quoted context omitted.

It looks that Dhall has been inspired of the Elm language [0] and it's formatter. [0]: https://guide.elm-lang.org/

It's a common practice in the Haskell community. Knowing where the creator of dhall comes from I would say that that's the source of inspiration

Author here: the syntax is inspired by all three of Haskell/PureScript/Elm
Post reply on HN