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

Edward Z. Yang ezyang at mit.edu
Fri Sep 16 02:23:56 UTC 2016

On September 16, 2016 9:19:16 AM GMT+09:00, Christopher Allen <cma at bitemyapp.com> wrote:
>The YAML parser backing hpack and Stack supports a subset of yaml, so
>the complexity isn't there.

Is the subset of yaml that Stack supports deacribed anywhere? The yaml package (which Stack depends on) seems to suggest it supports a pretty beefy chunk of YAML, e.g. including includes.

>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.

I'm not suggesting you change over. My feeling is that once a choice like this is made, it is very hard to change post facto. Need to build infrastructure for migrating to new format if you do.

>Keep in mind while discussing all this that Cabal's own solver doesn't
>actually live outside of cabal-install.

Here is the ticket tracking the issue:

Basically, everyone agrees it should happen, but there is a bit of work that has to be done, esp. API design, and most of us have other issues we are frying.

> Contributing to the Cabal
>project itself is a gauntlet run, which is partly why many of these
>projects spawned outside of it.

I know that this was true in the past, and it is hard to regain trust and reputation. But I think things are better now. Our turnaround time for new PRs is now much quicker, and if you submit a PR we will give you commit bits. Obviously that doesn't make up for any past failings, but please give us another look!

> Further, Cabal itself can't really
>grow any dependencies because of the bootstrap problem.

I don't think this is inherently unsolvable. Just work. It would be reasonable to remove Cabal from boot packages GHC distributes and require cabal-install/Stack to bootstrap a sufficiently new version of Cabal library. But you would have to do work to make sure that you dont end up building half the universe on a fresh GHC build. GHC devs would not like that.

>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.

Out of curiosity, what are the libraries that are most painful to not have available from the boot libraries?


>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
>>> flexible and open, used across many tools so the knowledge of format
>>> more widely sharable which has its advantages. Are there reasons to
>>> using the cabal format other than the legacy reasons and the pain of
>>> 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
>> Cabal's lexical format is very simple, because it doesn't really need
>> support much (the rest is deferred to sub-parsers on fields.)  In
>> since, YAML is overkill for Stack, which actually doesn't use very
>many of
>> its features
>> If I were designing a package ecosystem from scratch, I'm not sure
>> format I would pick.  Take Rust Cargo; they didn't use YAML, they
>> 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
>>> YAML over .cabal. I guess it might be similar to the reasons why
>>> 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
>>> of the problems of the format are addressed. Maintaining a closed
>>> perennially is also an issue unless it is very well thought out and
>>> not require any changes.
>> I suspect the reason is much more banal: Cabal's parser
>> is pretty byzantine and difficult to use. So rather than fight
>> 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

Sent from my Android device with K-9 Mail. Please excuse my brevity.

More information about the Haskell-Cafe mailing list