Cabal stack

[soupi]

lhbg-book has a chapter about defining a project description and shows how to use both stack and cabal. Both seem to be pretty similar for basic usage imo.

[Martinsos]

Thanks for sharing -> that book is a very cool effort! I ended up not going into details of defining project in stack/cabal, instead I just focused on high-level stuff that should help you when making a decision if you should use cabal or stack and understanding the difference between them. Btw I noticed you don't mention package.yaml, how is that? In order to avoid additional complexity of having to explain that next to .cabal?

[soupi]

Primarily because package.yaml aren't really needed to develop Haskell program. They are pretty much the same as cabal files and one needs to understand cabal files anyway, so I don't see a lot of value from covering them - users can just use cabal files instead. If at some point a user would still like to use them, it should be very straightforward to understand them if one understand cabal files because it's mostly just the syntax that's different :)

[Martinsos]

Makes sense. Although I had a bit different story -> I have been using Stack since I started with Haskell, and I had no idea that package.yaml is same as .cabal for a very long time, until recently actually. I was just working on package.yaml, as instructed by the Stack docs. So I don't think one needs to understand cabal file to be able to work with package.yaml, or even know what cabal is, but on the other hand if you do know about .cabal file, then package.yaml is trivial. And vice versa, in big part. So it makes sense that you don't explain both since they are the same. Maybe it is worth mentioning that package.yaml exists?

[soupi]

Tbh I don't feel super strongly about this, your experience definitely makes sense. I feel there are many opportunities for cabal-file users and package.yaml users to be exposed to the other format (because package.yaml generates cabal files, and because cabal files generated by package.yaml has a comment saying that they are generated) and as you said it's probably easy to learn one after you understand the other.

So at that point of time I think that rather than having an extensive guide covering all bases, I think it's more important to give a learner one format (the primary format) that they can use, and trust that if they will need (or decide to) switch, they'll be able to in the future.