Migrate from the .cabal format to a widely supported format

In the wake of the [exact-printer](https://github.com/haskell/cabal/issues/7544) initiative, [I proposed another approach](https://twitter.com/Profpatsch/status/1426523345730908161): why not say good bye to the .cabal file format and switch to something that is widely supported. There is a few alternatives, the most important attribute would be that they are widely supported in industry. - JSON - YAML - TOML Note that all of these are (mostly) isomorphic to JSON (scalars, lists, dicts), which is important for easy translation between them (e.g. for config generation purposes). ## What would this give the Haskell ecosystem? - Editor support: every modern editor like `vscode` has a way of assigning JSON schema to a file, which gives completion and inline documentation for free everywhere - Also, syntax highlighting and auto formatting come for free - Cabal doesn’t need to implement its own parser. If JSON is chosen, the parser is even context-free. ## What would it give to users? - Instant familiarity with the format: you don’t touch cabal files all too often as a user, so you don’t want to learn yet another syntax - Templating cabal config with standard tooling (e.g. `jq`, `yj`), which is important e.g. in a monorepo context - Inline documentation without setup ## What are others doing? Most modern package managers that don’t go the full turing-complete configuration route (e.g. Scala’s sbt, Erlang) usually converge their config on a widely supported syntax. Examples

Posted by Profpatsch on Aug 15, 2021, 1:39 PM

Tags

• support (Software)

Related issues

• Add 65536 size support for maps
• TypeScript 7.1 Iteration Plan
• nvim-treeconfig: upstream nvim-treesitter
• Add the "action" and "method" attributes to <button>
• [FEATURE] Support multiple Connector accounts (same connector, different accounts) in Claude and Claude Code on the web (claude.ai/code)
• > We were imposed GitHub for so many exercises!