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

[Neil Mitchell]

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
>