Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries

[Iavor Diatchki]

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 at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>