Add haskell exercises' dependency control.

[rbasso]

Install three files:

• dependencies.txt - List of dependencies for all Haskell sources.
• dependencies - Shell script to query dependencies.
• stackalize - Shell script to convert an exercise in a stack project.

Sample usage:

$ dependencies go-counting
array
base
containers
HUnit

$ dependencies `ls exercises`
array
attoparsec
...
time
vector

$ dependencies --only-in-examples `ls exercises`
attoparsec
lens
..
split
stm

$ cd exercises/leap
$ stackalize --resolver lts-6.4
...
$ stack test
$ stackalize --undo

Closes #151

[rbasso]

This may not be the best dependency control system designed by humankind, but I expect it to work well enough, and it's better to have something than nothing. 😄

stackalize is in the pack because it depends on dependencies, and it is the simplest way I found to get a running environment to run the tests and check if the dependencies are correctly specified. It also makes very easy to test locally against multiple GHC versions before committing.

[rbasso]

The dependency-list for each of the exercises was successfully tested in individual stack projects with Travis, using lts-2.22 (ghc-7.8.4), lts-6.4 (ghc-7.10.3) and nightly-2016-06-21 (ghc-8.0.1). The dependencies of tests and examples were specified and tested independently, so they can be regarded as correct.

[petertseng]

Perhap I'll have to grab Stack and play around with it this weekend to try out the effects of this for myself. I can reason about bash well enough to understand what's here though.

One interesting question I had is - we would want to note somewhere that adding a new exercise to this track will also want the dependencies added to dependencies.txt, right? Unless I missed a way to automatically populate that file

[petertseng]

hmm, would you explain to me what happens if not moving files to here? What would break? Maybe worth a comment here, unless you think it's obvious to anyone who knows what they doing (I certainly don't with Stack, I know)

[rbasso]

First, you need to know that this is not the best example of bash scripting in the world. It's just something that I improvised to solve this problem. 😄

What the script does is:

• move everything to .extraFiles, so we get a known directory struture.
• move from there the example and test files to their correct locations.
• generate a stack.yaml with the provided resolver.
• generate a package.yaml (simpler than a .cabal file) with the correct dependencies.

It can centainly be improved, but It's been 17 years since the last time I played with bash as a sysadmin. Let's say it works under normal conditions. 😁

About your question, if there are additional source files in the directory, as in forth and zipper, they could be included accidentally in the project and break the build. Also, I wanted to be able to unstackalize the project, moving everything back to their places.

[rbasso]

If you think these scripts deserve a complete rewrite, fell free to change anything. I just need a way to assemble the project.

I did this in bash so it could run without additional dependencies. That's convenient for Travis.

[rbasso]

Added the comments explaining the move to .extraFiles. Thanks again! 😄
Now working on the README.md.

[rbasso]

You are correct, @petertseng.

It is, in fact, impossible to automatically populate the dependencies, so that would demand an update to the README.md explaining to the contributors that the file must reflect the dependencies.

It's a way to enforce good discipline and minimize maintenance. It would also allow reproducible build environments for contributors.

If in the future we move to stack based tests, Travis will check for correctly specified dependencies automatically.

[rbasso]

Added a new README.md with some instructions for contributors on how to use stack.

Also updated the list of packages and included a small section mentioning dependency control.

[rbasso]

Considering that this PR only adds functionalities and updates an outdated documentation file, there is no risk in merging it now, even if there are some problem with the scripts we are not catching until now.

This way we can at least keep the dependency list updated and start testing #162.

[petertseng]

I'm late to the show but you correctly determined you didn't need to wait for me. And I would have said 👍 anyway.