Clean up SubHask's dependencies

[mikeizbicki]

There's been issues regarding SubHask having too many dependencies for some people, particularly with hmatrix and Windows (see #22). Now that SubHask has a Haskell-native implementation of matrix multiplication (#32), it would be possible to remove the hmatrix dependency, and place that in a different package for anyone who wants faster matrix multiplications.

Some things that need to get done for that to happen:

1. Decide what the ideal package hierarchy would look like. In the past, I've had lots of issues with maintainability when separating out a package into multiple packages. I know other projects do this, but I'm not sure what the current best practices here is. Part of this is also deciding which dependencies besides hmatrix should be factored out, and which should be kept. I'm not sure what a good rule of thumb for this is.
2. Benchmarks for the native matrix multiplication so that users can have an idea of how much speed they're sacrificing by not installing hmatrix and dependencies.

[tonyday567]

Not being on stack is an important data point, so gamma, continued-fractions and converge would be great to carve out (or get into stack). Ditto c code: cbits/Lebesgue.c, Maybe swap erf-native for erf - but I cant think of a solid reason why.

The main dividing line looks like the compatibility layers - look at how HyperLogLog pulls in a lens dependency. But if/until this part grows, the dependency list looks skinny compared with others.

If you're not in a particular hurry, I'll volunteer for the benchmarking.

[mikeizbicki]

I agree that being in stack seems like a good dividing line, except that the most problematic package (hmatrix) is in stack.

There's no urgent rush for this. It probably makes most sense for you to benchmark the matrix ops since you implemented them.

[mrkkrp]

Can you also make dependency bounds more flexible? Stack helps with reproducible builds anyway. I was having a lot of problems trying to play with HLearn because of this.

I would be also great to be able to compile this with GHC 7.10.3.

[mikeizbicki]

@mrkkrp I'm not sure what you mean by more flexible dependency bounds. If you look in the cabal file, you'll see there are no dependencies bounds at all: https://github.com/mikeizbicki/subhask/blob/master/subhask.cabal#L129

[mrkkrp]

Huh, interesting. I cloned the HLearn repo recursively and there are bounds. When you clone the HLearn repo you get subhask-0.1 (24) but actual master is subhask-0.1 (48). I'll re-try to compile it use use with HLearn.

[mrkkrp]

I'm glad you pointed out this, as I will have another chance to try to make it work, thanks!