search

mikeizbicki / subhask

Type safe interface for working in subcategories of Hask
BSD 3-Clause "New" or "Revised" License
418 stars 43 forks source link

Clean up SubHask's dependencies #37

Open mikeizbicki opened 8 years ago

mikeizbicki commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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