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

hmm, that's the most convincing argument I've seen so far, so I'll try to see what still doesn't seem right to me: - if you'd release a separate package then would it have a 0.x version number now, or 1.0 -- does it have a degree of initial stableness? (should anything be assumed to have that the first time it's put on Hackage, if it's new?) - Luckily we don't have to worry much about release cycles -- we just make a new release of even ghc-boot-libs whenever we want to change anything in it, more-or-less (I think?) - Dependencies in cabal files are a bigger problem. They make it painful to split packages later... especially if you split them soon after adding something to them (e.g. bytestring, though that was worse because it involved base as well as GHC internals). But if you can be sure you're not going to want to remove it, it's only slightly painful in terms of allowed dependencies (e.g. can't use with an earlier version of containers, and clients have to specify dependency by containers version-number) Krasimir Angelov wrote:

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

---

Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

---

Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries