Chris A.

@robinp that's probably the most straight-forward way to go about it. @MichaelXavier sound copacetic to you?

I agree, it's a weird vestige of an off-hand thought I had a long time ago. Thank you!

This looks promising, thank you! /cc @MichaelXavier where are you at ES version-wise in production?

@PierreR I'm still here, I believe Michael is too. At present adding a new major (the 6 in 6.4.2) Elasticsearch version means duplicating a fair chunk of the source tree...

@danidiaz > is not likely to be interested in various versions of the API at the same time Bzzzzt. Elasticsearch versions matter big time. You've got the use-case backwards. This...

@danidiaz that sounds about like what I'd end up doing with nested datatypes. I'd love to see a worked example but I'm not sure how to keep that sort of...

https://ghc.haskell.org/trac/ghc/wiki/Performance/Compiler https://ghc.haskell.org/trac/ghc/ticket/5642 Then from: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/GenericDeriving Also: https://github.com/tfausak/tfausak.github.io/issues/127 My understanding that the more work GHC had to do in a single module, the slower the build got overall. I'm going to...

Part of the thinking here is that there's a lot of excessive allocation and retained heap for compiling one-big-module and that some speed benefits would be obtained from splitting that...

Follow-up thought: TH is reportedly _much_ faster than Generics for almost all purposes of deriving class instances. Example: https://github.com/tfausak/rattletrap/pull/58#issuecomment-352065871 Taylor's been very helpful in all this btw. Another option I...

I've been working on http://hackage.haskell.org/package/hedgehog-checkers and http://hackage.haskell.org/package/hedgehog-checkers-lens — I think I'd prefer #2, which is also something I'm willing to help out with. I'll start a branch for us tonight...