[Haskell-community] [Haskell-cafe] technical thoughts on stack

[Edward Z. Yang]

> How about cabal-install using the YAML format as hpack has proven that it
> works very well for expressing the existing .cabal files? YAML is simple,
> flexible and open, used across many tools so the knowledge of format is
> more widely sharable which has its advantages. Are there reasons to keep
> using the cabal format other than the legacy reasons and the pain of asking
> everyone to move to another format?

I understand YAML is a very popular format, but it is not all roses.
It's an extremely complicated format (http://yaml.org/spec/1.2/spec.html).
Cabal's lexical format is very simple, because it doesn't really need to
support much (the rest is deferred to sub-parsers on fields.)  In some
since, YAML is overkill for Stack, which actually doesn't use very many of
its features (https://docs.haskellstack.org/en/stable/yaml_configuration/)

If I were designing a package ecosystem from scratch, I'm not sure what
format I would pick.  Take Rust Cargo; they didn't use YAML, they used
TOML (https://github.com/toml-lang/toml) in no small part due to the
fact that YAML is complicated.  I'd want the output to be associated
with locations so I could give error messages that refer to the input
file; no one does that today...

> Inputs from original stack authors might also be useful on why they chose
> YAML over .cabal. I guess it might be similar to the reasons why someone
> wrote hpack to generate .cabal from YAML. Also they were starting fresh and
> so did not have to manage a disruptive change. But I fear if they will be
> willing to go for a closed format against an open format now even if some
> of the problems of the format are addressed. Maintaining a closed format
> perennially is also an issue unless it is very well thought out and does
> not require any changes.

I suspect the reason is much more banal: Cabal's parser implementation
is pretty byzantine and difficult to use. So rather than fight something
like that, just use something will a nicer API.

Edward