Re:Dhall: A Non-Repetitive Alternative to YAML
by singpolyma3 on Friday July 05, 2019 @08:34PM
(#20366970)
> 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
by eridius on Friday July 05, 2019 @04:27AM
(#20360799)
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.
Re:Dhall: A Non-Repetitive Alternative to YAML
by hjk05 on Friday July 05, 2019 @11:27AM
(#20363258)
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.
Re:Dhall: A Non-Repetitive Alternative to YAML
by eridius on Friday July 05, 2019 @05:56PM
(#20366207)
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.
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).