5 ms·
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 co
by 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 agoI 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 agoStrong 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 agoI 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?