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

[Krasimir Angelov]

Ups! According to the library submission procedure this message should
have been sent to libraries at haskell.org. I appologise for the multiple
copies.


---------- Forwarded message ----------
From: Krasimir Angelov <kr.angelov at gmail.com>
Date: Sat, May 31, 2008 at 10:42 AM
Subject: Re: [Haskell-cafe] Data.Tree.Zipper in the standard libraries
To: Haskell-cafe <haskell-cafe at haskell.org>


Hi again,

I was silent for some time but in this time I created QuickCheck tests
for Data.Tree.Zipper which achieve 100% coverage with HPC. I also
created a ticket for it: Ticket #2324

http://hackage.haskell.org/trac/ghc/ticket/2324

The attached file is the current implementation and it contains the
version updated from Iavor Diatchki. It has the advantage that it also
works with forests, not just with trees.

Initially I thought that complete testsuite for such a simple module
might be overkill but actually I found a bug :-) in the splitChildren
function which is now fixed.

The dead line for further considerations is one week.

Regards,
 Krasimir



On Sun, May 25, 2008 at 1:09 AM, Iavor Diatchki
<iavor.diatchki at gmail.com> wrote:
> Hello,
> I think that the modified API (no state monad, and using Maybe) is
> quite nice!  I implemented a version of the the suggested API using a
> slightly different data structure, which makes the code a bit simpler,
> I think.   I put the code in the Haskell wiki:
> http://www.haskell.org/sitewiki/images/2/2d/RoseZipper.hs
> I also added a couple of extra functions that seemed useful, and
> renamed a few of the functions to be more consistent.
>
> As for how to distribute the code, it seems that Zipper should live in
> the same place as Data.Tree.  I think that Data.Tree is part of the
> "containers" package, so it would make sense to add the Zipper there
> as well.
>
> -Iavor
>
>
>
> On Sat, May 24, 2008 at 1:24 AM, Neil Mitchell <ndmitchell at gmail.com> wrote:
>> Hi,
>>
>>> It doesn't use State monad anymore and it returns Maybe. This seems to
>>> be the common preference, is it? Feel free to vote against. Should we
>>> change Data.Map also? There is another proposal for changes in
>>> findMin/findMax so it is better to make this two breaking changes
>>> together rather than in a later release.
>>
>> The standard libraries proposal thingy is to go via the libraries
>> list, create tickets etc. What reason is there to make this part of
>> the base libraries, rather than a separate package on hackage? I can't
>> see much reason to make Data.Tree part of the base libraries, other
>> than the fact it already is, and it could easily get moved out at a
>> future date.
>>
>> We've seen there is some advantage in leaving the implementation
>> outside the base library, as its already changed several times in the
>> past few days.
>>
>> Thnanks
>>
>> Neil
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>