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

Ups! According to the library submission procedure this message should have been sent to libraries@haskell.org. I appologise for the multiple copies. ---------- Forwarded message ---------- From: Krasimir Angelov Date: Sat, May 31, 2008 at 10:42 AM Subject: Re: [Haskell-cafe] Data.Tree.Zipper in the standard libraries To: Haskell-cafe 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 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 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe