Simon wrote, > Manuel: would you like to talk to Ben, Gabi, Roman, and decide what you'd > like us to do for the release. Specifically: > > - Release with DPH, or rely on 'cabal install dph'? > - Push the new refactoring into the branch; or not?
Below I attach a summary of our Tuesday Skype call. I would like to stick to the plan that we formulated during that call — that is: * Release 7.0 including DPH using the new library that is based on vector. My reasons for this decision: * If we ship the old code base with the release, we won't be able to maintain it. (We just lost our main DPH developer.) Performance supposedly already broke with the new type checker — i.e., it'll be DOA. * Maybe it is easy to make cabal install handle the DPH libraries, maybe not. I believe it when I see it and at the moment it doesn't work. * This has all been dragging out for too long already. If we don't use the release as a forcing function, it'll drag out again (despite the best intentions of all involved). Roman, SimonM wrote he added the lagging repositories. Could you please push the patches now? Manuel -=- In a Skype call between the Simons @ GHC HQ and the UNSW DPH group, we discussed the new dependency of DPH on the vector package. The following is the conclusion we came to. Background: * DPH consists of both a compiler component (the vectoriser) and a library (package dph). * The library consists of multiple GHC packages (dph-base, dph-prim-interface, dph-prim-seq, dph-prim-par, dph-seq & dph-par), which are build in a non-standard way. (This is necessary as dph-seq and dph-par are supposed to be interchangeable.) * The vector package started its life as an experimental revision of one of the DPH library packages, namely dph-prim-seq. The plan was always that vector, once sufficiently mature, would replace dph-prim-seq. * While maturing, vector took on a life of its own and achieved a certain popularity. (A nice success story for DPH, as it makes some of the DPH technology accessible to the community, while we are still busy working on the rest.) * Obviously, it makes no sense to maintain the vector package on Hackage separately from the new dph-prim-seq replacement in DPH. After Roman's benchmarks showed a few month ago that package vector is on par or exceeds the performance of dph-prim-seq in all respects, it was time to finally replace dph-prim-seq with vector. Our goal is to complete this transition before the imminent release candidate for GHC 7.0 to facilitate the exchange of patches between what will be the new stable branch of the compiler and the development version. As a result vector will be necessary to build GHC and being kept in a lagging repository (while being maintained outside of GHC), and hence, it will inadvertently appear in the Haskell Platforms once it incorporates GHC 7.0. This has been the case for all DPH packages so far (including the pre-vector dph-prim-seq), but may send a different message due to vector's existing popularity. In contrast to some other boot packages (namely, haskelline, mtl, and terminfo) that are used to build GHC, but are not installed, we cannot avoid to install the packages of the DPH library as they cannot currently be built separately. This is due to the non-standard build procedure mentioned previously. The only reasonable solution at the moment appears to proceed with the integration of vector into DPH in time for the release candidate and to apply for inclusion of package vector and package primitive (on which vector depends) into the Haskell Platform. The rest of DPH (both the vectoriser and the other library packages) will remain an experimental feature of GHC as before. We formally don't regard primitive and vector to be part of the Haskell Platform until the proposal processes for these packages have completed, and we understand that may entail API changes and perhaps even package name changes (in the case of primitive). This is not unlike the GHC package, which is distributed with GHC by necessity, but is not subject to the scrutiny of the platform proposal process and shouldn't be considered a "standard" package in any sense. _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
