GHC 7.10.1

[mchakravarty]

Seems like GHC HQ has more resources and pushes out releases faster now. They have posted GHC 7.10.1RC1 already: https://www.haskell.org/pipermail/ghc-devs/2014-December/007781.html

Did anybody try this with Accelerate yet? They seem to aim for a release in Feb.

[yongqli]

We tried it, but Repa doesn't work with 7.10 right now.

[mchakravarty]

@yongqli Why do you need Repa for that?

[tmcdonell]

I guess accelerate-io and the canny example program?

[yongqli]

Yes, we use accelerate-io, but not repa.

[tmcdonell]

accelerate-io pulls in repa because it includes the instances for converting between Accelerate and Repa arrays.

[yongqli]

Would it be possible to separate out repa related code into another package, accelerate-repa or something? We would like to transition to 7.10 ASAP, and it's not clear when repa would be ready for 7.10. Would you accept a pull request if we went ahead and did this?

[mchakravarty]

Separating it out sounds like a reasonable proposal to me. Repa is a quite heavy dependency.

[robeverest]

Could we not have repa support as a cabal flag for accelerate-io, rather than make it a whole other package?

[tmcdonell]

@robeverest In this case the cabal flag option might do the sensible thing --- since we will default the flag to on, we need cabal to automatically disable the flag if can't find a suitable version to install, which I think it does, but I'm not sure. #243 had pretty poor handling of cabal flags.

@yongqli If you are trying to install all of accelerate-examples, I expect you'll run into exactly the same problem when you reach gloss-accelerate and friends...

I think it is time for me to download the 7.10RC...

[mchakravarty]

@robeverest In my experience, flags in cabal packages that affect dependencies create more problems than they solve. The reason is that, once installed, it is not transparent whether a package has been compiled with a particular flag set or not. In other words, clients of a package with flags can only depend on the package as a whole, but not on a package compiled with a particular set of flags.

In our example, a client of accelerate-io cannot depend on accelerate-io with Repa support. Hence, depending on flag settings, clients will fail to compile despite all dependencies being fulfilled.

In contrast, if the condition is expressed in the form of a separate package, such as accelerate-repa, a client can explicitly depend on that, so that, if Repa support is missing in a particular installation, Cabal's dependency checking fails appropriately.

It is annoying that this leads to a proliferation of small packages, but with Cabal in its current form, I don't see any practical alternative.

[tmcdonell]

0.15.1 patch releases are finally out, which are compatible with ghc-7.8 and ghc-7.10.

[mchakravarty]

Great — thank you. Next Haskell for Mac release will have GHC 7.10 and Accelerate 0.15.1.