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

[Christopher Allen]

The YAML parser backing hpack and Stack supports a subset of yaml, so
the complexity isn't there.

TOML isn't supported because a well-supported/known-good library
wasn't to hand, whereas the yaml one did. I don't think people would
mind changing over, but somebody has to do the work validating that
the one-still-maintained-of-two-libraries TOML library is suitable.

Keep in mind while discussing all this that Cabal's own solver doesn't
actually live outside of cabal-install. Contributing to the Cabal
project itself is a gauntlet run, which is partly why many of these
projects spawned outside of it. Further, Cabal itself can't really
grow any dependencies because of the bootstrap problem.

Nobody wants to shim / inline all the dependencies that enable the
devs to work efficiently into Cabal and such a PR would never get
merged anyway.

On Thu, Sep 15, 2016 at 6:55 PM, Edward Z. Yang <ezyang at mit.edu> wrote:
>> 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
> _______________________________________________
> Haskell-community mailing list
> Haskell-community at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community



-- 
Chris Allen
Currently working on http://haskellbook.com