6 ms·

Dhall heavily borrows both ideas and syntax from the ML family of languages. E.g. Haskell, OCaml, Elm, Purescript Colons are used for type signatures. Commas

by duijf 7y ago

Dhall heavily borrows both ideas and syntax from the ML family of languages. E.g. Haskell, OCaml, Elm, Purescript Colons are used for type signatures. Commas are presumably required because you can have multi line and nested records. (don't quote me on this, not a parser expert) The comment syntax is from Haskell. Not saying this syntax is familiar to everyone, but it is familiar to some. The lineage of the syntax might help you understand where the language is coming from

dymk 7y ago
Weird that it's billed as an alternative to YAML, but effectively has zero roots or influence from YAML. Looks more like an alternative to... whatever configuration language is popular in ML language projects?
- londt8 7y ago
  Its more like an alternative to scripts generating configuration from templates. they claim that this is better because you cant for example write an infinite loop ruining the script.
  - owl57 7y ago
    Is it a real problem though? If your config generator is complex enough to hide an infinite loop, you probably should be relieved every time it fails obviously and doesn't generate wrong config instead.
- duijf 7y ago
  There aren't too many standard onrs. Most people seem to either write a custom (embedded) DSL for their tool or go with something more widely known. If people are curious about examples of DSLs in Haskell projects, they can look at cabal files, persistent's entity syntax, and servant's type level DSL for API definitions. These go on a scale from "fully separate" to "embedded in the language". (Persistent is in between, it uses something called Template Haskell) The stack Haskell build/project management tool uses YAML files. - - - I think Dhall's power is not that it is an alternative syntax to YAML. It's more about the typesystem than anything else. If you're sold on types, then Dhall is definitely worth a look
- Vosporos 7y ago
  So? They live in the same solution domain for the same problem. Moreover, Dhall can generate (typechecked) YAML and JSON.
  - dymk 7y ago
    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".
    - Jeff_Brown 7y ago
      > All I did was add another layer of complexity If that was in fact all you had done, it would not be worth it. But it might remove a ton of boilerplate from your YAML.
      - LoSboccacc 7y ago
        or, one can eliminate boilerplate in code so that configuration stays simple and the logic in the application I mean what's the role of configuration? is so that installer can tune or match environments. if configuration becomes as hard as your program to understand then installation won't ever scale
    - StreamBright 7y ago
      >> 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?
      - dymk 7y ago
        How many languages have an Dhall implementation? One?
- ben509 7y ago
  I disagree that it has zero roots. It's not whitespace sensitive, so it does throw out a ton of YAML's distinctive syntax. What you're left with is YAML's core expressiveness, which is that within a text file you can express the basic structures of maps, sequences, some atoms and user-typed [1] nodes. YAML also has some limited facilities for avoiding repetition, such as aliases and anchors[2]. And a YAML parser can use tags to simulate functions[3]. Dhall is preserving all those capabilities, and then adds real functions and type declarations to further expand the ability to avoid repetition and to avoid mistakes. It's also using a proper type system rather than basically returning a parse tree back. And whereas these advanced features in YAML are rarely useful because the parser has to go out of its way to support them, it seems like Dhall may be able to make them work properly. So I'd say seeing another project attempt something and then trying to do it right is definitely being influenced by it. [1]: https://yaml.org/spec/1.2/spec.html#id2761292 https://yaml.org/spec/1.2/spec.html#id2761292 [2]: https://yaml.org/spec/1.2/spec.html#id2786196 https://yaml.org/spec/1.2/spec.html#id2786196 [3]: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-sub.html https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...
nikolay 7y ago
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.
- ljm 7y ago
  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.
  - ben509 7y ago
    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 a reference implementation written in Haskell where they have very good pretty printing libraries so it's likely that programs would be able to do automated updates to configuration.
    - ff_ 7y ago
      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 https://github.com/spacchetti/spago [1]: https://github.com/spacchetti/spago/blob/a77b869edcfddd592f45726400b816de8c1f070e/src/Spago/Config.hs#L159 https://github.com/spacchetti/spago/blob/a77b869edcfddd592f4... [2]: http://www.haskellforall.com/2017/11/semantic-integrity-checks-are-next.html?showComment=1511801973283#c6412191866661551590 http://www.haskellforall.com/2017/11/semantic-integrity-chec...

by duijf 7y ago

dymk 7y ago

Weird that it's billed as an alternative to YAML, but effectively has zero roots or influence from YAML. Looks more like an alternative to... whatever configuration language is popular in ML language projects?

londt8 7y ago
Its more like an alternative to scripts generating configuration from templates. they claim that this is better because you cant for example write an infinite loop ruining the script.
- owl57 7y ago
  Is it a real problem though? If your config generator is complex enough to hide an infinite loop, you probably should be relieved every time it fails obviously and doesn't generate wrong config instead.
duijf 7y ago
There aren't too many standard onrs. Most people seem to either write a custom (embedded) DSL for their tool or go with something more widely known. If people are curious about examples of DSLs in Haskell projects, they can look at cabal files, persistent's entity syntax, and servant's type level DSL for API definitions. These go on a scale from "fully separate" to "embedded in the language". (Persistent is in between, it uses something called Template Haskell) The stack Haskell build/project management tool uses YAML files. - - - I think Dhall's power is not that it is an alternative syntax to YAML. It's more about the typesystem than anything else. If you're sold on types, then Dhall is definitely worth a look
Vosporos 7y ago
So? They live in the same solution domain for the same problem. Moreover, Dhall can generate (typechecked) YAML and JSON.
- dymk 7y ago
  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".
  - Jeff_Brown 7y ago
    > All I did was add another layer of complexity If that was in fact all you had done, it would not be worth it. But it might remove a ton of boilerplate from your YAML.
    - LoSboccacc 7y ago
      or, one can eliminate boilerplate in code so that configuration stays simple and the logic in the application I mean what's the role of configuration? is so that installer can tune or match environments. if configuration becomes as hard as your program to understand then installation won't ever scale
  - StreamBright 7y ago
    >> 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?
    - dymk 7y ago
      How many languages have an Dhall implementation? One?
ben509 7y ago
I disagree that it has zero roots. It's not whitespace sensitive, so it does throw out a ton of YAML's distinctive syntax. What you're left with is YAML's core expressiveness, which is that within a text file you can express the basic structures of maps, sequences, some atoms and user-typed [1] nodes. YAML also has some limited facilities for avoiding repetition, such as aliases and anchors[2]. And a YAML parser can use tags to simulate functions[3]. Dhall is preserving all those capabilities, and then adds real functions and type declarations to further expand the ability to avoid repetition and to avoid mistakes. It's also using a proper type system rather than basically returning a parse tree back. And whereas these advanced features in YAML are rarely useful because the parser has to go out of its way to support them, it seems like Dhall may be able to make them work properly. So I'd say seeing another project attempt something and then trying to do it right is definitely being influenced by it. [1]: https://yaml.org/spec/1.2/spec.html#id2761292 https://yaml.org/spec/1.2/spec.html#id2761292 [2]: https://yaml.org/spec/1.2/spec.html#id2786196 https://yaml.org/spec/1.2/spec.html#id2786196 [3]: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-sub.html https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...

nikolay 7y ago

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.

ljm 7y ago
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.
- ben509 7y ago
  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 a reference implementation written in Haskell where they have very good pretty printing libraries so it's likely that programs would be able to do automated updates to configuration.
  - ff_ 7y ago
    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 https://github.com/spacchetti/spago [1]: https://github.com/spacchetti/spago/blob/a77b869edcfddd592f45726400b816de8c1f070e/src/Spago/Config.hs#L159 https://github.com/spacchetti/spago/blob/a77b869edcfddd592f4... [2]: http://www.haskellforall.com/2017/11/semantic-integrity-checks-are-next.html?showComment=1511801973283#c6412191866661551590 http://www.haskellforall.com/2017/11/semantic-integrity-chec...