On September 16, 2016 9:19:16 AM GMT+09:00, Christopher Allen <c...@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: https://github.com/haskell/cabal/issues/3781 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? Edward >On Thu, Sep 15, 2016 at 6:55 PM, Edward Z. Yang <ezy...@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@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. _______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
