Simplify stack-7.8.yaml by basing it on a recent nightly

[sjakobi]

No description provided.

[mgsloan]

Great idea, thanks!

[sjakobi]

BTW, are we going to keep compatibility with GHC-7.8 once GHC-8.0 is released?

[mgsloan]

That's a good question! Remains to be seen, I think we will probably drop support for building stack with GHC 7.8 once we want to use some 7.10 feature (perhaps implicit callstacks?)

[sjakobi]

Given that commit history already contains a lot of compatibility fixes from the period when stack supported only two major GHC versions, I'm wondering if we can get a better story for supporting three…

Maybe a custom prelude could help. (Which could also help trim down the number of imports in each file…)

Another approach that has worked for me relatively well, is using the stack-7.8.yaml by default. This will sometimes result in warnings with the other versions (AMP, redundant constraints etc.) but usually not in actual errors. Making the stack-7.8.yaml the default stack.yaml might just be enough of an incentive for others to use that one too.

[mgsloan]

Yup! Some variety of custom prelude or import Import makes sense to me. I don't think @chrisdone is a fan of such modules, but perhaps it's ok if it purely consists of module re-exports?

I don't really find the burden of having travis tell me something is broken to be that big of a deal. The multi configurations aspect of #1568 could really help here