use stack to build and test

[gelisam]

The Travis tests are still failing, but only under some versions of GHC. But why am I even supporting more than one version of GHC? hawk is an executable, not a library. So let's use stack to fix a GHC version once and for all, and hopefully fix and simplify the TravisCI tests at the same time.

[gelisam]

Oh! It will fix the versions of every library too, so it will fix #149 for free!

[gelisam]

Wait. hawk is an executable, but it is used to run user-written Haskell scripts. And users can import arbitrary Haskell modules from their user prelude, as long as they're from a package which has been installed in the same sandbox as hawk is in. Do I want to limit users to stackage's packages?

[gelisam]

How about: next to the user prelude, we put a default stack.yaml, and users can modify it to add more packages if they want their user prelude to be able to access them. This would make user preludes portable across systems!

[gelisam]

...but then we're back to square one: if the user can modify the stack.yml file, they can change which version of GHC to use. Hmm.

[gelisam]

Maybe there's a way to separate the hawk executable from the haskell-awk library, and then we would only have to make sure haskell-awk is compatible with multiple versions of GHC?

[gelisam]

The most obvious difficulty is that hawk uses hint to interpret the piece of code which the user has written, using hint. This requires hawk to be compiled with the same version of GHC as the libraries which hint will be loading. So instead of using hint, how about using the ghc executable installed by stack? It's already possible to do ghc -e as a poor man's hawk, we could use ghc -e under the hood too, or maybe runhaskell.

[gelisam]

Or stack exec -- runhaskell!

[gelisam]

Okay, so I'm now convinced that this can work. But first things first: let's switch the build system to stack.

[gelisam]

Fixed by #173. I have opened #176 to track this new idea of putting a stack.yml next to the user prelude.