{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreif3sxq4icbo3ktupexhni4ghb63nng54jsrw5v722yv3tkoamzc4u",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mjsg2aem4ka2"
  },
  "path": "/t/config-languages-and-dhall/13948#post_10",
  "publishedAt": "2026-04-18T21:35:55.000Z",
  "site": "https://discourse.haskell.org",
  "textContent": "This matches my experience with Dhall, I’m afraid. Banning text comparison (IIRC to stop people writing languages within languages) and recursion (in service of Turing-incompleteness) really limits the language’s power. The type system also seems too strong (it had to give up have type inference, so you pass type parameters for basic FP idioms) and too weak (you can’t manipulate record types in the way a config language probably needs to). On top of all that, the language spec requires a parser that can keep multiple candidate parses around for quite some time, which means that a syntax error in a large document presents as `unexpected \",\"` at the other end of the file once the last candidate parse fails. Turing-incompleteness is a clever goal but presumably one could write a busy beaver that won’t run forever but will take longer than the user is prepared to wait.\n\nThis is all a big shame because a lot of the language is genuinely good. Web-based imports, the record-completion-with-defaults syntax, the enforced lack of side-effects are all great choices for a configuration language.\n\nMy general recommendation for tools is to just consume JSON and let the user choose whatever “configuration language” he prefers. Even if it’s something horrifically cursed like `m4`, it doesn’t become anyone else’s problem. There’s currently no clear winner in the configuration language space, and sadly there probably won’t be one unless it has a well-used Go implementation.",
  "title": "Config languages (and Dhall)"
}