4 ms·

One valuable point of Dhall is that it is programmable (yet not TC) in such a way to that you can e.g. describe a whole system entirely in Dhall and then (in Dh

One valuable point of Dhall is that it is programmable (yet not TC) in such a way to that you can e.g. describe a whole system entirely in Dhall and then (in Dhall!) derive whatever further configurations (plural!) you need from that. This is much more feasible than in e.g. YAML because Dhall is strongly typed. So you could describe e.g. a cluster of machines entirely in Dhall and derive Ansible YAML scripts (with all their boilerplate), derive DNS config files, etc. etc. all from a single strongly typed description.

Boulth 7y ago
It goes even further: because Dhall supports functions one can write a function that will migrate old configs to new format. Migration function can also be type checked (it must accept old config format and emit new one). Of course all of this without TC.
cryptonector 7y ago
I mean, jq is a powerful programming language. Did you look at the link I posted?
- jessaustin 7y ago
  Well, you did format it so that it's not clickable...
- Quekid5 7y ago
  Sure, I'm familiar with it. It's nothing compared to what Dhall can do. ... unless of course it's grown to a similar point. As of about a year ago, for some complex transformations I had to stitch together multiple invocations of jq using pipes, etc. etc. That may have been my inexperience with using it, though. Regardless, the point about typing stands. Dhall uses structural typing/subtyping which turns out to be hugely useful for config transformation.
  - cryptonector 7y ago
    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).
    - Quekid5 7y ago
      > 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 thing.
      - cryptonector 7y ago
        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.
        Quekid5 7y ago
        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?

Boulth 7y ago

It goes even further: because Dhall supports functions one can write a function that will migrate old configs to new format. Migration function can also be type checked (it must accept old config format and emit new one). Of course all of this without TC.

cryptonector 7y ago

I mean, jq is a powerful programming language. Did you look at the link I posted?

jessaustin 7y ago
Well, you did format it so that it's not clickable...
Quekid5 7y ago
Sure, I'm familiar with it. It's nothing compared to what Dhall can do. ... unless of course it's grown to a similar point. As of about a year ago, for some complex transformations I had to stitch together multiple invocations of jq using pipes, etc. etc. That may have been my inexperience with using it, though. Regardless, the point about typing stands. Dhall uses structural typing/subtyping which turns out to be hugely useful for config transformation.
- cryptonector 7y ago
  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).
  - Quekid5 7y ago
    > 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 thing.
    - cryptonector 7y ago
      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.
      - Quekid5 7y ago
        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?