Hello, Neil, nobody is suggesting to add the zipper to the "base" package, we are talking about the "containers" package, which is also available from hackage (http://hackage.haskell.org/cgi-bin/hackage-scripts/package/containers) . The whole point of splitting the large "base" library was so that we can update the different components separately. In general, I agree with Neil's sentiment that we don't want to lump together things that are conceptually different because the extra dependencies make it harder to update packages. However, we should also watch out for the other extreme---where each module ends up in a separate package. While this leads to the most flexibility, it also introduces extra overhead in managing the dependencies, and finding the libraries that we need. In this case, the zipper is the iterator type for trees, so I think that it is justified to add it to the same package as trees. As for the discussion about tests: I don't see how writing down the properties of the program (e.g., in the form of QC properties) can be a bad thing, so I really think that it is great the Krasimir took the time to provide a set of tests for the zipper implementation. We need more of this sort of thing, not less! The fact that the GHC test suite is taking too long to run, should not dictate how programmers test their libraries. If there is a pragmatic problem, I think that Duncan's suggests provide a good solution---simply run the tests more selectively. -Iavor On Mon, Jun 2, 2008 at 4:11 AM, Neil Mitchell <ndmitchell@gmail.com> wrote:
Hi
well. The process package seems to have quite different API now. Even if the zipper is in different package then this doesn't mean that we don't have to care about the backward compatibility.
If the package lives on its own, the author is responsible for it. If you decide you made a mistake in the interface you can change it (I did this for TagSoup). If you want to provide a backwards compatible version you provide Data.Zipper.OldVersion (I did this for FilePath). If you want to move the module you can do so (I did this for Safe). If you want to add new features you can do so without asking anyone (I did this for Yhc.Core). If you want to optimise the code you can do so without asking anyone (I did this for Homeomorphic).
There are many benefits to having a package outside the base library. In 3 of the above cases being inside the base library would have mean I just couldn't do what I wanted. In the last 2 cases I would have had to submit library proposals. I think that new big features live best in a separate package, at least until a couple of people have played with them and incrementally improved them. As Hackage improves, the benefits of being in the base library decrease substantially.
Thanks
Neil _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries