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

Isaac Dupree isaacdupree at charter.net
Mon Jun 2 06:28:56 EDT 2008


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



More information about the Libraries mailing list