Drop support for pre-8.0 GHC

[treeowl]

It seems impossible (or extremely difficult) to offer Lift instances for GHC versions before 8.0. Old versions of template-haskell depended on containers, making it impossible to depend on them. There are newer versions of template-haskell that claim to build with the relevant GHC versions, but Cabal refuses, considering template-haskell "non-upgradable". That leaves us a few options:

1. Leave well enough alone, allowing the instances to stay in th-lift-instances. This is blecherous, of course.
2. Export the instances for GHC 8.0 and later, allowing th-lift-instances to cover earlier versions. Not exactly ideal.
3. Drop support for GHC < 8.0. This would remove all the immediate problems except for people who care about earlier versions. Since DeriveLift also appeared in 8.0, most instances could be derived (the Seq instance wants a bit of special treatment).

Longer-term concerns about depending on template-haskell:

1. template-haskell won't be able to depend directly on containers. I don't imagine this is a serious problem.
2. template-haskell can't depend indirectly on containers either. This means that pretty can't depend on containers. It's managed this long without doing so, so I guess that's probably fine, but if it finds itself needing any containers-like structures, it'll have to reimplement them itself.

[treeowl]

@phadej, @dterei, @ndmitchell, your comments on the potential impact of a template-haskell dependency would be greatly appreciated.

[Bodigrim]

Dropping GHC < 8.0 is IMO no-brainer, pretty much every other package (e. g., bytestring, text, random, primitive, vector) has done it already. Old versions of containers are not going anywhere.

[phadej]

My opinion hasn't changed: #807 (comment)

[ndmitchell]

Strongly agreed with this idea. I'd drop < 8.6 support at the same time. Do people from the stone age really need the latest containers? I'd say not... But if 8.0 is the threshold that makes your lives easier, sounds great.

If you can avoid the TH dependency your life will be easier. But whatever you need to do.

[treeowl]

@phadej thoughts on the TH dependency? @ndmitchell easier how?

[phadej]

@treeowl the template-haskell dependency is fine. I have no idea what @ndmitchell has in mind, but I don't know how importing Lift to DeriveLift would make anything harder in the long run. (Manual instance for Seq is unfortunate, it would be great to have a way to use DeriveLift but also "normalise" the value before lifting. That would be useful for e.g. Text too: it should slice the underlying bytearray)

[treeowl]

@phadej the instance is "semi-automatic" already thanks to the use of quotes. I don't know how your could hope to insert a normalization step with less code; there's basically no boilerplate. And it doesn't just normalize; it also shifts/merges coercions.

[ndmitchell]

Generally TH slows down builds, changes in each version, doesn't work on all platforms or stage1 compilers - it's got a lot of things that make things a bit different. I avoid it where I can, so it's definitely easier without, but not a big deal with it.

[phadej]

@ndmitchell you confuse using TH and depending on template-haskell (library) to provide instances/functionality (without using TH itself).

[treeowl]

@ndmitchell we only need TemplateHaskellQuotes, which seems to be a less troublesome extension. Is that also problematic for stage 1?

[phadej]

@treeowl it isn't. It's exactly why it was introduced: to be used in stage 1 -like compilers without full TH support.

[phadej]

@treeowl

I don't know how your could hope to insert a normalization step with less code

With current deriving mechanism I indeed cannot. And in Seq case it's not bad as Seq is just a newtype wrapper. But it would be great to be able to generate anonymous functions which is liftTyped (or fmap, or traverse or ...) for any type (given its structure is visible). Another use case is to be able to use GHC.Generics without deriving the instance, that would be convenient for opaque types.

[treeowl]

@phadej, I agree that being able to derive method implementations rather than just classes would sometimes be useful. It would not, however, be useful for Data.Sequence.Seq (because of the Elem stuff). It would also have limited utility in general for recursively defined types. Once you get past the first level, you hit the need for an instance, either for the type in question or some other type.