headers
Neil Mitchell | 1 Jun 2008 16:17
Picon
Gravatar

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

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:
(Continue reading)

Permalink | Reply | 36 comments |
headers
Isaac Dupree | 1 Jun 2008 18:49
Favicon

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

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?

'containers', not 'base'.  But still, I think it should stay in a 
separate package.  Someday Data.Tree may be removed from the more-used 
containers too.  (do we know who does use Data.Tree, btw?)

-Isaac
Permalink | Reply | 3 comments |
headers
Ross Paterson | 1 Jun 2008 19:14
Picon
Favicon

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

On Sun, Jun 01, 2008 at 12:49:39PM -0400, Isaac Dupree wrote:
> 'containers', not 'base'.  But still, I think it should stay in a  
> separate package.  Someday Data.Tree may be removed from the more-used  
> containers too.  (do we know who does use Data.Tree, btw?)

Data.Graph for one.
Permalink | Reply | 1 comment |
headers
Aaron Denney | 1 Jun 2008 20:14
X-Face

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

On 2008-05-31, 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.

Ian does have a point that there is a lot of wasted effort.  Perhaps the
flow can be optimized so that these tests aren't run as often.

One would get nearly the same benefit if they're only run right before
major distribution, to keep buggy versions from widespread usage.  Then,
the patch that caused the bug can easily be tracked down by bisection.

Even if they're never run automatically on every change, they're a
valuable bit of documentation: they're an unambiguous machine-readable
specification of several properties that are expected to hold.

--

-- 
Aaron Denney
-><-
Permalink | Reply | 0 comments |
headers
Thorkil Naur | 1 Jun 2008 21:18
Picon

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

Hello,

Just for the record: I agree fully with the opinion expressed here by Ian.

Best regards
Thorkil
On Saturday 31 May 2008 13:16, Ian Lynagh wrote:
> On Sat, May 31, 2008 at 10:44:40AM +0200, Krasimir Angelov wrote:
> > 
> > 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.
> 
> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Duncan Coutts | 1 Jun 2008 22:26
Picon
Picon
Favicon

Re: hackage, package list, trac, some suggestions/questions


On Sat, 2008-05-31 at 11:40 +0100, Ross Paterson wrote:
> On Sat, May 31, 2008 at 12:21:21AM +0100, Claus Reinke wrote:
> > good point. as .cabal files are served as text, they might be
> > scanned as well. still, i'd think that hackage should do as good
> > mailing list archives do: obfuscate email addresses to make
> > harvesting more difficult, without users having to obfuscate
> > things by hand.
> > 
> > if someone figures out how to install the package descriptions
> > on their own machine for harvesting, there isn't much to be done
> > about that, just as with harvesters registering on mailing lists.
> > but one shouldn't make it too easy..
> 
> The .cabal file is still inside the tarball, and unpacking archives is
> a standard thing for web traversers to do -- no installation necessary.
> The only thing that would work is for the upload script to modify the
> cabal file inside package, which is something I'm reluctant to do,
> because it intrudes on the domain of the maintainer.

And would mess up md5sums etc.

Duncan
Permalink | Reply | 0 comments |
headers
Duncan Coutts | 1 Jun 2008 22:30
Picon
Picon
Favicon

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


On Sun, 2008-06-01 at 12:49 -0400, Isaac Dupree wrote:
> 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?
> 
> 'containers', not 'base'.  But still, I think it should stay in a 
> separate package.  Someday Data.Tree may be removed from the more-used 
> containers too.  (do we know who does use Data.Tree, btw?)

It's used ad-hoc in lots of programs whenever people want a rose-tree.
It's convenient to have and as Ross says it's used in the public
interface of Data.Graph. If anything I think it should be extended. For
example where is the post-order flattening, the all-paths etc. There are
useful operations defined for it in Data.Graph that should be moved to
Data.Tree itself.

Duncan
Permalink | Reply | 0 comments |
headers
Duncan Coutts | 1 Jun 2008 22:42
Picon
Picon
Favicon

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


On Sat, 2008-05-31 at 10:10 -0700, Don Stewart wrote:

> You're on your own on this one, Ian. QuickCheck is a cheap, simple way
> to get good coverage, that's why Haskell library writers use it.
> 
> Please include tests, Krasimir!

Ian does have a point. We're talking about two different testing
contexts:

      * GHC nightly builds
      * tests run on commits by developers

I absolutely agree with you Don about the second context. That's the one
eg for bytestring where we found lots of our own stupid mistakes before
they caused segfaults for end users. It vital for initial development
and for making subsequent changes to the library.

On the other hand Ian is quite right that for GHC nightly builds (where
you're not actually making any changes to the module) it does seem like
a lot of wasted effort to run the same tests again and again.

Perhaps we can see a way to run the right tests in the right context. If
there have been changes then the full QC testsuite is demanded. If on
the other hand we're just looking at a system level integration test
then perhaps we do not need to run all the tests at a maximum level of
coverage.

Perhaps we could take a probabilistic approach. How about a QC test
(Continue reading)

Permalink | Reply | 0 comments |
headers
Krasimir Angelov | 2 Jun 2008 09:12
Picon
Gravatar

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

and also Gtk2Hs, Yi, GF, XML Toolbox and probably some other.

On 6/1/08, Ross Paterson <ross <at> soi.city.ac.uk> wrote:
> On Sun, Jun 01, 2008 at 12:49:39PM -0400, Isaac Dupree wrote:
> > 'containers', not 'base'.  But still, I think it should stay in a
> > separate package.  Someday Data.Tree may be removed from the more-used
> > containers too.  (do we know who does use Data.Tree, btw?)
>
> Data.Graph for one.
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
Permalink | Reply | 0 comments |
headers
Krasimir Angelov | 2 Jun 2008 09:20
Picon
Gravatar

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

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
(Continue reading)

Permalink | Reply | 31 comments |

Gmane