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

Krasimir Angelov kr.angelov at gmail.com
Mon Jun 2 03:20:52 EDT 2008


I don't propose to add it to base but to containers where the
Data.Tree module already is. This sounds like a logical place for me.
The implementation has been changed but I can't say that it was
rewritten from scratch. Part of my idea was to share what I use and to
hear some ideas for improvements. That is exactly what happened and I
am quite satisfied. Even if it has to be changed later I don't see any
problem with this. Changes are made to the Map and Set modules as
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.

On 6/1/08, Neil Mitchell <ndmitchell at gmail.com> wrote:
> Hi Krasimir,
>
> What is the strong justification for adding this to the base library?
> Is there some particular reason that it can't be done outside of base,
> or is there some particular need that makes this code desirable in the
> base libraries? Could it be added as a separate library on hackage,
> worked on for a while, and then merged into the base latter if
> appropriate?
>
> I worry that in the last couple of weeks since you first brought this
> code up it seems like its been reimplemented from scratch with a
> different interface. Once it goes in the base library, those decisions
> are fixed in stone. If it gets some real world use in a library first,
> then its much clearer if there are any flaws or extensions required.
>
> Thanks
>
> Neil
>
>
> On Sat, May 31, 2008 at 6:12 PM, Don Stewart <dons at galois.com> wrote:
> > It's not wasted work. As far as I know, only Ian advocates against
> > including tests.
> >
> > Having worked on several data structure libraries, I've found that
> > QuickCheck regularly catches errors that appear, and ensure over the
> > long term that code remains stable.
> >
> > -- Don
> >
> > kr.angelov:
> >> In this case the recommendation to write QuickCheck tests should be
> >> removed from the library submission procedure. I don't want to do
> >> wasted work again!
> >>
> >> On Sat, May 31, 2008 at 1:16 PM, Ian Lynagh <igloo at earth.li> wrote:
> >> > So just to check, this proposal is to add Data.Tree.Zipper to containers
> >> > and the QC tests to the testsuite, right?
> >> >
> >> > As I've explained before[1], I don't think that QuickCheck tests are a
> >> > good way to test libraries: They tend to test the same inputs (e.g. [])
> >> > or equivalent inputs (e.g. "insert 2 [3]" and "insert 3 [4]") many
> >> > times, meaning it takes much longer to get the same level of testing as
> >> > a few well-chosen unit tests. When you multiply this by all the
> >> > libraries the testsuite is meant to test, this is a significant amount
> >> > of time.
> >> >
> >> > I also don't think that adding the tests but not running them
> >> > automatically is a good idea, as they will most likely just bitrot.
> >> >
> >> > Adding a unit test for the bug you found is certainly a good idea,
> >> > though!
> >> >
> >> >
> >> > [1] http://www.haskell.org/pipermail/libraries/2008-April/009594.html
> >> >
> >> >
> >> > Thanks
> >> > Ian
> >> >
> >> >
> >> _______________________________________________
> >> Libraries mailing list
> >> Libraries at haskell.org
> >> http://www.haskell.org/mailman/listinfo/libraries
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://www.haskell.org/mailman/listinfo/libraries
> >
>


More information about the Libraries mailing list