From ndmitchell at gmail.com Sun Jun 1 10:17:47 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun Jun 1 10:10:33 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <20080531171212.GB32271@scytale.galois.com> References: <8339047720729393098@unknownmsgid> <404396ef0805240124p2ac50bdfq6f79d3c5f7306efb@mail.gmail.com> <5ab17e790805241609p64ece4beo8aeb6fec3e26ef14@mail.gmail.com> <20080531111658.GA31519@matrix.chaos.earth.li> <20080531171212.GB32271@scytale.galois.com> Message-ID: <404396ef0806010717o145a7f20rf05ed9c4f7d803bb@mail.gmail.com> 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 > From isaacdupree at charter.net Sun Jun 1 12:49:39 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Sun Jun 1 12:42:24 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <404396ef0806010717o145a7f20rf05ed9c4f7d803bb@mail.gmail.com> References: <8339047720729393098@unknownmsgid> <404396ef0805240124p2ac50bdfq6f79d3c5f7306efb@mail.gmail.com> <5ab17e790805241609p64ece4beo8aeb6fec3e26ef14@mail.gmail.com> <20080531111658.GA31519@matrix.chaos.earth.li> <20080531171212.GB32271@scytale.galois.com> <404396ef0806010717o145a7f20rf05ed9c4f7d803bb@mail.gmail.com> Message-ID: <4842D323.6070001@charter.net> 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 From ross at soi.city.ac.uk Sun Jun 1 13:14:38 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sun Jun 1 13:07:26 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <4842D323.6070001@charter.net> References: <404396ef0805240124p2ac50bdfq6f79d3c5f7306efb@mail.gmail.com> <5ab17e790805241609p64ece4beo8aeb6fec3e26ef14@mail.gmail.com> <20080531111658.GA31519@matrix.chaos.earth.li> <20080531171212.GB32271@scytale.galois.com> <404396ef0806010717o145a7f20rf05ed9c4f7d803bb@mail.gmail.com> <4842D323.6070001@charter.net> Message-ID: <20080601171438.GA3492@soi.city.ac.uk> 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. From wnoise at ofb.net Sun Jun 1 14:14:35 2008 From: wnoise at ofb.net (Aaron Denney) Date: Sun Jun 1 14:07:35 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries References: <20080523174504.GB4034@scytale.galois.com> <8339047720729393098@unknownmsgid> <404396ef0805240124p2ac50bdfq6f79d3c5f7306efb@mail.gmail.com> <5ab17e790805241609p64ece4beo8aeb6fec3e26ef14@mail.gmail.com> <20080531111658.GA31519@matrix.chaos.earth.li> <20080531171212.GB32271@scytale.galois.com> Message-ID: On 2008-05-31, 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. 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 -><- From naur at post11.tele.dk Sun Jun 1 15:18:44 2008 From: naur at post11.tele.dk (Thorkil Naur) Date: Sun Jun 1 15:14:07 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <20080531111658.GA31519@matrix.chaos.earth.li> References: <20080531111658.GA31519@matrix.chaos.earth.li> Message-ID: <200806012118.57473.naur@post11.tele.dk> 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 > 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 > From duncan.coutts at worc.ox.ac.uk Sun Jun 1 16:26:53 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Jun 1 16:16:22 2008 Subject: hackage, package list, trac, some suggestions/questions In-Reply-To: <20080531104004.GA13080@soi.city.ac.uk> References: <20080530151335.GA11901@soi.city.ac.uk> <20080531104004.GA13080@soi.city.ac.uk> Message-ID: <1212352013.15010.100.camel@localhost> 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 From duncan.coutts at worc.ox.ac.uk Sun Jun 1 16:30:43 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Jun 1 16:20:11 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <4842D323.6070001@charter.net> References: <8339047720729393098@unknownmsgid> <404396ef0805240124p2ac50bdfq6f79d3c5f7306efb@mail.gmail.com> <5ab17e790805241609p64ece4beo8aeb6fec3e26ef14@mail.gmail.com> <20080531111658.GA31519@matrix.chaos.earth.li> <20080531171212.GB32271@scytale.galois.com> <404396ef0806010717o145a7f20rf05ed9c4f7d803bb@mail.gmail.com> <4842D323.6070001@charter.net> Message-ID: <1212352243.15010.104.camel@localhost> 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 From duncan.coutts at worc.ox.ac.uk Sun Jun 1 16:42:50 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Jun 1 16:32:25 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <20080531171057.GA32271@scytale.galois.com> References: <20080523072806.GA2713@soi.city.ac.uk> <20080523174504.GB4034@scytale.galois.com> <8339047720729393098@unknownmsgid> <404396ef0805240124p2ac50bdfq6f79d3c5f7306efb@mail.gmail.com> <5ab17e790805241609p64ece4beo8aeb6fec3e26ef14@mail.gmail.com> <20080531111658.GA31519@matrix.chaos.earth.li> <20080531171057.GA32271@scytale.galois.com> Message-ID: <1212352970.15010.117.camel@localhost> 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 driver that runs say 2 instances of each QC property at the same QC Aribtrary 'size' as you'd hit when you do the full 100 tests. That way each nightly run tests a different sample and we don't just keep hitting the 0/[] cases (though we will still hit 0/[] sometimes, the 'size' parameter is a maximum not minimum). It should still catch the obvious integration bugs (like changed semantics of imported modules). Then we can do 'full' runs at important junctures like release candidates. Duncan From kr.angelov at gmail.com Mon Jun 2 03:12:53 2008 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Mon Jun 2 03:05:37 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <20080601171438.GA3492@soi.city.ac.uk> References: <5ab17e790805241609p64ece4beo8aeb6fec3e26ef14@mail.gmail.com> <20080531111658.GA31519@matrix.chaos.earth.li> <20080531171212.GB32271@scytale.galois.com> <404396ef0806010717o145a7f20rf05ed9c4f7d803bb@mail.gmail.com> <4842D323.6070001@charter.net> <20080601171438.GA3492@soi.city.ac.uk> Message-ID: and also Gtk2Hs, Yi, GF, XML Toolbox and probably some other. On 6/1/08, Ross Paterson 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@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From kr.angelov at gmail.com Mon Jun 2 03:20:52 2008 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Mon Jun 2 03:13:36 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <404396ef0806010717o145a7f20rf05ed9c4f7d803bb@mail.gmail.com> References: <404396ef0805240124p2ac50bdfq6f79d3c5f7306efb@mail.gmail.com> <5ab17e790805241609p64ece4beo8aeb6fec3e26ef14@mail.gmail.com> <20080531111658.GA31519@matrix.chaos.earth.li> <20080531171212.GB32271@scytale.galois.com> <404396ef0806010717o145a7f20rf05ed9c4f7d803bb@mail.gmail.com> Message-ID: 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 > > > From isaacdupree at charter.net Mon Jun 2 06:28:56 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Mon Jun 2 06:21:38 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: References: <404396ef0805240124p2ac50bdfq6f79d3c5f7306efb@mail.gmail.com> <5ab17e790805241609p64ece4beo8aeb6fec3e26ef14@mail.gmail.com> <20080531111658.GA31519@matrix.chaos.earth.li> <20080531171212.GB32271@scytale.galois.com> <404396ef0806010717o145a7f20rf05ed9c4f7d803bb@mail.gmail.com> Message-ID: <4843CB68.5010904@charter.net> 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 > From ndmitchell at gmail.com Mon Jun 2 07:11:02 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Jun 2 07:03:45 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <4843CB68.5010904@charter.net> References: <5ab17e790805241609p64ece4beo8aeb6fec3e26ef14@mail.gmail.com> <20080531111658.GA31519@matrix.chaos.earth.li> <20080531171212.GB32271@scytale.galois.com> <404396ef0806010717o145a7f20rf05ed9c4f7d803bb@mail.gmail.com> <4843CB68.5010904@charter.net> Message-ID: <404396ef0806020411v5ef46278gd1ae8ee29c3ce805@mail.gmail.com> Hi >> 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. If the package lives on its own, the author is responsible for it. If you decide you made a mistake in the interface you can change it (I did this for TagSoup). If you want to provide a backwards compatible version you provide Data.Zipper.OldVersion (I did this for FilePath). If you want to move the module you can do so (I did this for Safe). If you want to add new features you can do so without asking anyone (I did this for Yhc.Core). If you want to optimise the code you can do so without asking anyone (I did this for Homeomorphic). There are many benefits to having a package outside the base library. In 3 of the above cases being inside the base library would have mean I just couldn't do what I wanted. In the last 2 cases I would have had to submit library proposals. I think that new big features live best in a separate package, at least until a couple of people have played with them and incrementally improved them. As Hackage improves, the benefits of being in the base library decrease substantially. Thanks Neil From iavor.diatchki at gmail.com Mon Jun 2 14:57:44 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon Jun 2 14:50:27 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <404396ef0806020411v5ef46278gd1ae8ee29c3ce805@mail.gmail.com> References: <20080531111658.GA31519@matrix.chaos.earth.li> <20080531171212.GB32271@scytale.galois.com> <404396ef0806010717o145a7f20rf05ed9c4f7d803bb@mail.gmail.com> <4843CB68.5010904@charter.net> <404396ef0806020411v5ef46278gd1ae8ee29c3ce805@mail.gmail.com> Message-ID: <5ab17e790806021157k33ab6a06n982746fe9ccae678@mail.gmail.com> Hello, Neil, nobody is suggesting to add the zipper to the "base" package, we are talking about the "containers" package, which is also available from hackage (http://hackage.haskell.org/cgi-bin/hackage-scripts/package/containers) . The whole point of splitting the large "base" library was so that we can update the different components separately. In general, I agree with Neil's sentiment that we don't want to lump together things that are conceptually different because the extra dependencies make it harder to update packages. However, we should also watch out for the other extreme---where each module ends up in a separate package. While this leads to the most flexibility, it also introduces extra overhead in managing the dependencies, and finding the libraries that we need. In this case, the zipper is the iterator type for trees, so I think that it is justified to add it to the same package as trees. As for the discussion about tests: I don't see how writing down the properties of the program (e.g., in the form of QC properties) can be a bad thing, so I really think that it is great the Krasimir took the time to provide a set of tests for the zipper implementation. We need more of this sort of thing, not less! The fact that the GHC test suite is taking too long to run, should not dictate how programmers test their libraries. If there is a pragmatic problem, I think that Duncan's suggests provide a good solution---simply run the tests more selectively. -Iavor On Mon, Jun 2, 2008 at 4:11 AM, Neil Mitchell wrote: > Hi > >>> 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. > > If the package lives on its own, the author is responsible for it. If > you decide you made a mistake in the interface you can change it (I > did this for TagSoup). If you want to provide a backwards compatible > version you provide Data.Zipper.OldVersion (I did this for FilePath). > If you want to move the module you can do so (I did this for Safe). If > you want to add new features you can do so without asking anyone (I > did this for Yhc.Core). If you want to optimise the code you can do so > without asking anyone (I did this for Homeomorphic). > > There are many benefits to having a package outside the base library. > In 3 of the above cases being inside the base library would have mean > I just couldn't do what I wanted. In the last 2 cases I would have had > to submit library proposals. I think that new big features live best > in a separate package, at least until a couple of people have played > with them and incrementally improved them. As Hackage improves, the > benefits of being in the base library decrease substantially. > > Thanks > > Neil > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From ndmitchell at gmail.com Mon Jun 2 18:05:25 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Jun 2 17:58:07 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <5ab17e790806021157k33ab6a06n982746fe9ccae678@mail.gmail.com> References: <20080531111658.GA31519@matrix.chaos.earth.li> <20080531171212.GB32271@scytale.galois.com> <404396ef0806010717o145a7f20rf05ed9c4f7d803bb@mail.gmail.com> <4843CB68.5010904@charter.net> <404396ef0806020411v5ef46278gd1ae8ee29c3ce805@mail.gmail.com> <5ab17e790806021157k33ab6a06n982746fe9ccae678@mail.gmail.com> Message-ID: <404396ef0806021505q39ef04e3ib5ba878b967b72e2@mail.gmail.com> Hi > Neil, nobody is suggesting to add the zipper to the "base" package, we > are talking about the "containers" package, which is also available I was referring to base as "the set of Core libraries" - my terminology was wrong, but my arguments were written with me thinking "containers", so still apply. > In this case, the zipper is the iterator type for trees, so I think > that it is justified to add it to the same package as trees. Talking to people on IRC today it appears there is a reasonably large design space for a zipper interface. If this is true, then putting a zipper in the containers package without some significant real-world experience is probably premature. Thanks Neil From kr.angelov at gmail.com Tue Jun 3 02:54:32 2008 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Tue Jun 3 02:47:12 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <404396ef0806021505q39ef04e3ib5ba878b967b72e2@mail.gmail.com> References: <20080531111658.GA31519@matrix.chaos.earth.li> <20080531171212.GB32271@scytale.galois.com> <404396ef0806010717o145a7f20rf05ed9c4f7d803bb@mail.gmail.com> <4843CB68.5010904@charter.net> <404396ef0806020411v5ef46278gd1ae8ee29c3ce805@mail.gmail.com> <5ab17e790806021157k33ab6a06n982746fe9ccae678@mail.gmail.com> <404396ef0806021505q39ef04e3ib5ba878b967b72e2@mail.gmail.com> Message-ID: On 6/3/08, Neil Mitchell wrote: > Talking to people on IRC today it appears there is a reasonably large > design space for a zipper interface. If this is true, then putting a > zipper in the containers package without some significant real-world > experience is probably premature. Well if this is the common agreement then I will withdraw my proposal. Maintaining a single module package floating around is too much effort for me. I prefer to keep a local copy in the projects that need it instead of maintaining an extra dependencies and to force the users to download extra software. I am sorry for the wasted time and effort. Krasimir From bernardy at chalmers.se Tue Jun 3 03:51:27 2008 From: bernardy at chalmers.se (Jean-Philippe Bernardy) Date: Tue Jun 3 03:44:07 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <404396ef0806021505q39ef04e3ib5ba878b967b72e2@mail.gmail.com> References: <20080531111658.GA31519@matrix.chaos.earth.li> <20080531171212.GB32271@scytale.galois.com> <404396ef0806010717o145a7f20rf05ed9c4f7d803bb@mail.gmail.com> <4843CB68.5010904@charter.net> <404396ef0806020411v5ef46278gd1ae8ee29c3ce805@mail.gmail.com> <5ab17e790806021157k33ab6a06n982746fe9ccae678@mail.gmail.com> <404396ef0806021505q39ef04e3ib5ba878b967b72e2@mail.gmail.com> Message-ID: <953e0d250806030051g7faffedav5872f9ca39dbe94@mail.gmail.com> On Tue, Jun 3, 2008 at 12:05 AM, Neil Mitchell wrote: > Talking to people on IRC today it appears there is a reasonably large > design space for a zipper interface. If this is true, then putting a > zipper in the containers package without some significant real-world > experience is probably premature. On the other hand, having something available in the containers package for everyone to experiment with seems a good way to evolve towards a better design. I'd still vote for adding the module, and flag it with "experimental" stability if there are worries of instability. Cheers, JP. From ndmitchell at gmail.com Tue Jun 3 04:58:29 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Jun 3 04:51:09 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <953e0d250806030051g7faffedav5872f9ca39dbe94@mail.gmail.com> References: <20080531171212.GB32271@scytale.galois.com> <404396ef0806010717o145a7f20rf05ed9c4f7d803bb@mail.gmail.com> <4843CB68.5010904@charter.net> <404396ef0806020411v5ef46278gd1ae8ee29c3ce805@mail.gmail.com> <5ab17e790806021157k33ab6a06n982746fe9ccae678@mail.gmail.com> <404396ef0806021505q39ef04e3ib5ba878b967b72e2@mail.gmail.com> <953e0d250806030051g7faffedav5872f9ca39dbe94@mail.gmail.com> Message-ID: <404396ef0806030158g41601671t41843824e51bfc5@mail.gmail.com> Hi > On the other hand, having something available in the containers package > for everyone to experiment with seems a good way to evolve towards a > better design. > > I'd still vote for adding the module, and flag it with "experimental" > stability if > there are worries of instability. If you want to mark it as experimental, it should not be in the core libraries. Evolving designs are great, but libraries@ should not be the maintainer of such a module. I'm not sure if that is a general policy, but I would be surprised to hear if it was a minority opinion. > Well if this is the common agreement then I will withdraw my proposal. > Maintaining a single module package floating around is too much effort > for me. I prefer to keep a local copy in the projects that need it > instead of maintaining an extra dependencies and to force the users to > download extra software. I am sorry for the wasted time and effort. I think that's a real shame. Maintaining a cabal package is relatively little effort. I have several packages which are just one module long (see for example Safe - which is not only one module, but every definition within it is only one line!). With cabal-install, the extra effort to install dependencies is literally nothing - its all handled automatically. And once you've got some users, and some varied experience of using the library, then I think making a library proposal would be a good idea. Thanks Neil From simonpj at microsoft.com Tue Jun 3 10:24:26 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Jun 3 10:17:09 2008 Subject: hackage, package list, trac, some suggestions/questions In-Reply-To: <1212180723.15010.46.camel@localhost> References: <1212180723.15010.46.camel@localhost> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE5944B9F@EA-EXMSG-C334.europe.corp.microsoft.com> | > 3. the hackage package list ought to list successful and failed | > builds (simply a list of compiler versions, each one green | > or red, depending on success, with direct link to build/ | > failure log; this would fit into the one-line-per-package | > format) for each entry, and report them to package authors. Personally I think that the key innovation on Hackage would be a user feedback system, like the user reviews on Amazon. Users can: - give a mark out of 10 for a package - write a review (perhaps short): eg "a real struggle to build on Solaris" or "worked like a charm" The marks are averaged and displayed, so other users can pick ones with good reviews. Well-engineered packages would stand out. Simon From johan.tibell at gmail.com Tue Jun 3 11:05:02 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue Jun 3 10:57:42 2008 Subject: hackage, package list, trac, some suggestions/questions In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE5944B9F@EA-EXMSG-C334.europe.corp.microsoft.com> References: <1212180723.15010.46.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C32AE5944B9F@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <90889fe70806030805r6be88602ye9021846d84d0a5d@mail.gmail.com> On Tue, Jun 3, 2008 at 4:24 PM, Simon Peyton-Jones wrote: > Personally I think that the key innovation on Hackage would be a user feedback system, like the user reviews on Amazon. Users can: > > - give a mark out of 10 for a package > - write a review (perhaps short): eg "a real struggle to build on Solaris" or "worked like a charm" > > The marks are averaged and displayed, so other users can pick ones with good reviews. We could also build a recommender system with a little machine learning. "If you liked 'bytestring' you might also like...". ;) -- Johan From lemming at henning-thielemann.de Tue Jun 3 11:32:56 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Jun 3 11:25:34 2008 Subject: hackage, package list, trac, some suggestions/questions In-Reply-To: <90889fe70806030805r6be88602ye9021846d84d0a5d@mail.gmail.com> References: <1212180723.15010.46.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C32AE5944B9F@EA-EXMSG-C334.europe.corp.microsoft.com> <90889fe70806030805r6be88602ye9021846d84d0a5d@mail.gmail.com> Message-ID: On Tue, 3 Jun 2008, Johan Tibell wrote: > On Tue, Jun 3, 2008 at 4:24 PM, Simon Peyton-Jones > wrote: >> Personally I think that the key innovation on Hackage would be a user feedback system, like the user reviews on Amazon. Users can: >> >> - give a mark out of 10 for a package >> - write a review (perhaps short): eg "a real struggle to build on Solaris" or "worked like a charm" >> >> The marks are averaged and displayed, so other users can pick ones with good reviews. > > We could also build a recommender system with a little machine > learning. "If you liked 'bytestring' you might also like...". ... to download dependent packages. :-] From alfonso.acosta at gmail.com Tue Jun 3 14:55:05 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Tue Jun 3 14:47:51 2008 Subject: type-level integers using type families In-Reply-To: <483E1FCF.9000101@gmail.com> References: <483E1FCF.9000101@gmail.com> Message-ID: <6a7c66fc0806031155s3562cbbag7990814a0aeeeb56@mail.gmail.com> On Thu, May 29, 2008 at 5:15 AM, Peter Gavin wrote: > Has anyone else tried implementing type-level integers using type families? When I started to work on thetype-level and parameterized data packages, I considered using type-families and GADTs, but I found quite a few problems which have been nicely summarized by Benedikt in this thread. From iavor.diatchki at gmail.com Tue Jun 3 17:15:04 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue Jun 3 17:07:42 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <404396ef0806030158g41601671t41843824e51bfc5@mail.gmail.com> References: <20080531171212.GB32271@scytale.galois.com> <404396ef0806010717o145a7f20rf05ed9c4f7d803bb@mail.gmail.com> <4843CB68.5010904@charter.net> <404396ef0806020411v5ef46278gd1ae8ee29c3ce805@mail.gmail.com> <5ab17e790806021157k33ab6a06n982746fe9ccae678@mail.gmail.com> <404396ef0806021505q39ef04e3ib5ba878b967b72e2@mail.gmail.com> <953e0d250806030051g7faffedav5872f9ca39dbe94@mail.gmail.com> <404396ef0806030158g41601671t41843824e51bfc5@mail.gmail.com> Message-ID: <5ab17e790806031415r180985d6u651dd27d1ed6158f@mail.gmail.com> Hi, > I was referring to base as "the set of Core libraries" - my > terminology was wrong, but my arguments were written with me thinking > "containers", so still apply. You arguments suggest that every module should be in a separate package. In my experience this is a bad idea. > Talking to people on IRC today it appears there is a reasonably large > design space for a zipper interface. If this is true, then putting a > zipper in the containers package without some significant real-world > experience is probably premature. Could you elaborate on this? What are the different design choices that your IRC discussions revealed? The zipper for trees is a fairly standard structure so I would be very surprised if the interface becomes drastically different. I would grant you that we may want to add some more functions to the library at some point, but apart from that the basics really should be much like what Krasimir posted. > I think that's a real shame. Maintaining a cabal package is relatively > little effort. I have several packages which are just one module long > (see for example Safe - which is not only one module, but every > definition within it is only one line!). With cabal-install, the extra > effort to install dependencies is literally nothing - its all handled > automatically. And once you've got some users, and some varied > experience of using the library, then I think making a library > proposal would be a good idea. Mico-managing a slew of different packages is a pain, especially if you are actually serious about maintaining the packages. It also makes finding packages and keeping track of the dependencies between them hard---cabal-install only helps with downloading the right packages, and it is not always an option to use it. But enough general discussions :-) Do people find any concrete problems with the zipper implementation? -Iavor From ndmitchell at gmail.com Tue Jun 3 17:23:02 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Jun 3 17:15:39 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <5ab17e790806031415r180985d6u651dd27d1ed6158f@mail.gmail.com> References: <404396ef0806010717o145a7f20rf05ed9c4f7d803bb@mail.gmail.com> <4843CB68.5010904@charter.net> <404396ef0806020411v5ef46278gd1ae8ee29c3ce805@mail.gmail.com> <5ab17e790806021157k33ab6a06n982746fe9ccae678@mail.gmail.com> <404396ef0806021505q39ef04e3ib5ba878b967b72e2@mail.gmail.com> <953e0d250806030051g7faffedav5872f9ca39dbe94@mail.gmail.com> <404396ef0806030158g41601671t41843824e51bfc5@mail.gmail.com> <5ab17e790806031415r180985d6u651dd27d1ed6158f@mail.gmail.com> Message-ID: <404396ef0806031423h785aea6k88c893b10af11712@mail.gmail.com> Hi >> I was referring to base as "the set of Core libraries" - my >> terminology was wrong, but my arguments were written with me thinking >> "containers", so still apply. > > You arguments suggest that every module should be in a separate > package. In my experience this is a bad idea. I think that any brand new module being proposed for the Core libraries should first be available as a package, and then integrated into the Core libraries afterwards. I think the barrier for getting things in the Core libraries should be much higher. For non-Core libraries, I would advocate grouping modules by functionality into packages - but for non-Core libraries people are free to do whatever they want :-) >> Talking to people on IRC today it appears there is a reasonably large >> design space for a zipper interface. If this is true, then putting a > > Could you elaborate on this? What are the different design choices > that your IRC discussions revealed? ndm> I was wondering if there is just one way to do a zipper? _other person_> I've done them using several different interfaces, I'm not quite sure which one I like best yet. (I know who _other person_ is, but it seems unfair to quote IRC with names back at people, given the instant and non-committal nature of IRC) >> I think that's a real shame. Maintaining a cabal package is relatively >> little effort. I have several packages which are just one module long > > Mico-managing a slew of different packages is a pain, especially if > you are actually serious about maintaining the packages. It also > makes finding packages and keeping track of the dependencies between > them hard---cabal-install only helps with downloading the right > packages, and it is not always an option to use it. If you have a package for every single module, then yes. If not, then its not that bad. Yes, you need some more infrastructure, but Cabal provides most of it. Maintaining a zipper package for a few months really wouldn't be that much work. Thanks Neil From kr.angelov at gmail.com Wed Jun 4 02:29:28 2008 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Wed Jun 4 02:22:04 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <404396ef0806031423h785aea6k88c893b10af11712@mail.gmail.com> References: <4843CB68.5010904@charter.net> <404396ef0806020411v5ef46278gd1ae8ee29c3ce805@mail.gmail.com> <5ab17e790806021157k33ab6a06n982746fe9ccae678@mail.gmail.com> <404396ef0806021505q39ef04e3ib5ba878b967b72e2@mail.gmail.com> <953e0d250806030051g7faffedav5872f9ca39dbe94@mail.gmail.com> <404396ef0806030158g41601671t41843824e51bfc5@mail.gmail.com> <5ab17e790806031415r180985d6u651dd27d1ed6158f@mail.gmail.com> <404396ef0806031423h785aea6k88c893b10af11712@mail.gmail.com> Message-ID: On Tue, Jun 3, 2008 at 11:23 PM, Neil Mitchell wrote: > ndm> I was wondering if there is just one way to do a zipper? > _other person_> I've done them using several different interfaces, I'm > not quite sure which one I like best yet. > > (I know who _other person_ is, but it seems unfair to quote IRC with > names back at people, given the instant and non-committal nature of > IRC) I would prefer the important discussions to be led not in IRC but in the mailing list. I personally very rarely (almost never) go to channel #haskell because I can't concentrate on my work if I have to follow the endless discussions in the channel. By the way so far your voice seems to be the only one against. I would like to hear what the other guys think. Krasimir From johan.tibell at gmail.com Wed Jun 4 03:56:01 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed Jun 4 03:48:38 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <404396ef0806030158g41601671t41843824e51bfc5@mail.gmail.com> References: <20080531171212.GB32271@scytale.galois.com> <404396ef0806010717o145a7f20rf05ed9c4f7d803bb@mail.gmail.com> <4843CB68.5010904@charter.net> <404396ef0806020411v5ef46278gd1ae8ee29c3ce805@mail.gmail.com> <5ab17e790806021157k33ab6a06n982746fe9ccae678@mail.gmail.com> <404396ef0806021505q39ef04e3ib5ba878b967b72e2@mail.gmail.com> <953e0d250806030051g7faffedav5872f9ca39dbe94@mail.gmail.com> <404396ef0806030158g41601671t41843824e51bfc5@mail.gmail.com> Message-ID: <90889fe70806040056je4139f2x7abd6a8d52d7f68c@mail.gmail.com> On Tue, Jun 3, 2008 at 10:58 AM, Neil Mitchell wrote: > Hi > >> Well if this is the common agreement then I will withdraw my proposal. >> Maintaining a single module package floating around is too much effort >> for me. I prefer to keep a local copy in the projects that need it >> instead of maintaining an extra dependencies and to force the users to >> download extra software. I am sorry for the wasted time and effort. > > I think that's a real shame. Maintaining a cabal package is relatively > little effort. I have several packages which are just one module long > (see for example Safe - which is not only one module, but every > definition within it is only one line!). With cabal-install, the extra > effort to install dependencies is literally nothing - its all handled > automatically. And once you've got some users, and some varied > experience of using the library, then I think making a library > proposal would be a good idea. I looked through all packages published by you on Hackage (quite a few!) and all of them expect yhccore, proplang, GuiHaskell and firstify depend only on core packages (e.g. base, containers, mtl, etc.). None of the libraries depend on many small non-core package and at least one depends on big packages like gtk. In my experience maintaining all these "fine grained" packages with no or few dependencies is not that difficult. However, maintaining packages with many small dependencies is. In my opinion packages should be on a more coarse grained level than modules. Maybe one per task e.g. gtk for graphics, urllib for client side HTTP, etc. It's also the granularity that is used in other, more powerful packaging managers for Linux. Cheers, Johan From bulat.ziganshin at gmail.com Wed Jun 4 04:16:57 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Jun 4 04:16:16 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <90889fe70806040056je4139f2x7abd6a8d52d7f68c@mail.gmail.com> References: <20080531171212.GB32271@scytale.galois.com> <404396ef0806010717o145a7f20rf05ed9c4f7d803bb@mail.gmail.com> <4843CB68.5010904@charter.net> <404396ef0806020411v5ef46278gd1ae8ee29c3ce805@mail.gmail.com> <5ab17e790806021157k33ab6a06n982746fe9ccae678@mail.gmail.com> <404396ef0806021505q39ef04e3ib5ba878b967b72e2@mail.gmail.com> <953e0d250806030051g7faffedav5872f9ca39dbe94@mail.gmail.com> <404396ef0806030158g41601671t41843824e51bfc5@mail.gmail.com> <90889fe70806040056je4139f2x7abd6a8d52d7f68c@mail.gmail.com> Message-ID: <966143547.20080604121657@gmail.com> Hello Johan, Wednesday, June 4, 2008, 11:56:01 AM, you wrote: >>> Well if this is the common agreement then I will withdraw my proposal. >>> Maintaining a single module package floating around is too much effort i'm agree with Neil in this discussion. previously, we inflated Base package to huge size by allowing to include there everything that someone want to include. it was resulted in splitting up of Base which created a serious maintenance problem the same apply to core packages. while every concrete addition may look interesting and we may believe that there is just one way to do it, later we may end up with huge collection of weakly related functionality with unstable interfaces i prefer to keep these packages in maintained mode - i.e. everything included by general consensus on a basis of thorough investigation, so we may be sure that included functionality is really widely used and will stay unchanged. any experimental modules should go into other places idea of marking modules as experimental looks interesting, but 1) there is no tools to ensure that you don't import those experimental modules so they will become a part of library API anyway 2) i don't think that widely used packages should serve as basis for experiments so, i will prefer if interesting new code will be shared by other ways - wiki, hpaste, darcs repositories, new packages on hackage - TIMTOWTDI -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From duncan.coutts at worc.ox.ac.uk Wed Jun 4 05:14:44 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jun 4 05:03:53 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: References: <4843CB68.5010904@charter.net> <404396ef0806020411v5ef46278gd1ae8ee29c3ce805@mail.gmail.com> <5ab17e790806021157k33ab6a06n982746fe9ccae678@mail.gmail.com> <404396ef0806021505q39ef04e3ib5ba878b967b72e2@mail.gmail.com> <953e0d250806030051g7faffedav5872f9ca39dbe94@mail.gmail.com> <404396ef0806030158g41601671t41843824e51bfc5@mail.gmail.com> <5ab17e790806031415r180985d6u651dd27d1ed6158f@mail.gmail.com> <404396ef0806031423h785aea6k88c893b10af11712@mail.gmail.com> Message-ID: <1212570884.15010.251.camel@localhost> On Wed, 2008-06-04 at 08:29 +0200, Krasimir Angelov wrote: > On Tue, Jun 3, 2008 at 11:23 PM, Neil Mitchell wrote: > > ndm> I was wondering if there is just one way to do a zipper? > > _other person_> I've done them using several different interfaces, I'm > > not quite sure which one I like best yet. > > > > (I know who _other person_ is, but it seems unfair to quote IRC with > > names back at people, given the instant and non-committal nature of > > IRC) > > I would prefer the important discussions to be led not in IRC but in > the mailing list. I personally very rarely (almost never) go to > channel #haskell because I can't concentrate on my work if I have to > follow the endless discussions in the channel. By the way so far your > voice seems to be the only one against. I would like to hear what the > other guys think. I would tend to agree with Neil that significant additions to the core libraries should be proven first as separate packages and integrated later. Duncan From Malcolm.Wallace at cs.york.ac.uk Wed Jun 4 05:39:20 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Jun 4 05:33:32 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <1212570884.15010.251.camel@localhost> References: <4843CB68.5010904@charter.net> <404396ef0806020411v5ef46278gd1ae8ee29c3ce805@mail.gmail.com> <5ab17e790806021157k33ab6a06n982746fe9ccae678@mail.gmail.com> <404396ef0806021505q39ef04e3ib5ba878b967b72e2@mail.gmail.com> <953e0d250806030051g7faffedav5872f9ca39dbe94@mail.gmail.com> <404396ef0806030158g41601671t41843824e51bfc5@mail.gmail.com> <5ab17e790806031415r180985d6u651dd27d1ed6158f@mail.gmail.com> <404396ef0806031423h785aea6k88c893b10af11712@mail.gmail.com> <1212570884.15010.251.camel@localhost> Message-ID: <20080604103920.5865d0c3.Malcolm.Wallace@cs.york.ac.uk> Duncan Coutts wrote: > I would tend to agree with Neil that significant additions to the core > libraries should be proven first as separate packages and integrated > later. +1 Regards, Malcolm From iavor.diatchki at gmail.com Wed Jun 4 13:14:59 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed Jun 4 13:07:35 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <20080604103920.5865d0c3.Malcolm.Wallace@cs.york.ac.uk> References: <5ab17e790806021157k33ab6a06n982746fe9ccae678@mail.gmail.com> <404396ef0806021505q39ef04e3ib5ba878b967b72e2@mail.gmail.com> <953e0d250806030051g7faffedav5872f9ca39dbe94@mail.gmail.com> <404396ef0806030158g41601671t41843824e51bfc5@mail.gmail.com> <5ab17e790806031415r180985d6u651dd27d1ed6158f@mail.gmail.com> <404396ef0806031423h785aea6k88c893b10af11712@mail.gmail.com> <1212570884.15010.251.camel@localhost> <20080604103920.5865d0c3.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <5ab17e790806041014i5624fc7fkcde64aca7472659a@mail.gmail.com> Hi, If this is the consensus, than people that feel this way should write a document describing the new process so that we know how to contribute code. Based on the current sentiments, we should decide at least on the following: - what is a "core" package Perhaps, a package that is distributed with GHC? But then, we should be having this discussion on the GHC users list... Also, was not the whole point of splitting the base library, so that we can gain the freedom to update libraries independent of implementations? - what constitutes a "significant" change Not sure how to define this. I would be weary of changes to the existing functions/types in the APIs of existing modules. But adding extra functionality? Especially, if---like in the case of Zipper---the implementation can be more or less computed from an existing definition in the package (I am referring to the fact that the zipper is the derivative of Tree, for details you can look at Conor's paper). - what makes code "proven" Again, not sure how to define this. The code for Zipper has QC tests that cover it 100%, according to HPC. Of course, this does not mean that it is perfect, but certainly should give us some assurance that it works. Does code have to sit on hackage for a certain amount of time, before it can be added to the libraries? Or are we going to require that it is already used by many people as a separate package, and then we are going to ask everyone to change their code, so that they can start using it from the new location? Neither option seems very nice. But more to the point though, does anyone have any suggestions about what may be wrong with the Zipper concretely, rather then the library process in general? Neil, the sniplet that you posted from the IRC channel does not give us an idea of what we might want to change. -Iavor On Wed, Jun 4, 2008 at 2:39 AM, Malcolm Wallace wrote: > Duncan Coutts wrote: > >> I would tend to agree with Neil that significant additions to the core >> libraries should be proven first as separate packages and integrated >> later. > > +1 > > Regards, > Malcolm > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From dons at galois.com Wed Jun 4 13:40:05 2008 From: dons at galois.com (Don Stewart) Date: Wed Jun 4 13:32:51 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <1212570884.15010.251.camel@localhost> References: <4843CB68.5010904@charter.net> <404396ef0806020411v5ef46278gd1ae8ee29c3ce805@mail.gmail.com> <5ab17e790806021157k33ab6a06n982746fe9ccae678@mail.gmail.com> <404396ef0806021505q39ef04e3ib5ba878b967b72e2@mail.gmail.com> <953e0d250806030051g7faffedav5872f9ca39dbe94@mail.gmail.com> <404396ef0806030158g41601671t41843824e51bfc5@mail.gmail.com> <5ab17e790806031415r180985d6u651dd27d1ed6158f@mail.gmail.com> <404396ef0806031423h785aea6k88c893b10af11712@mail.gmail.com> <1212570884.15010.251.camel@localhost> Message-ID: <20080604174005.GA19197@scytale.galois.com> duncan.coutts: > > On Wed, 2008-06-04 at 08:29 +0200, Krasimir Angelov wrote: > > On Tue, Jun 3, 2008 at 11:23 PM, Neil Mitchell wrote: > > > ndm> I was wondering if there is just one way to do a zipper? > > > _other person_> I've done them using several different interfaces, I'm > > > not quite sure which one I like best yet. > > > > > > (I know who _other person_ is, but it seems unfair to quote IRC with > > > names back at people, given the instant and non-committal nature of > > > IRC) > > > > I would prefer the important discussions to be led not in IRC but in > > the mailing list. I personally very rarely (almost never) go to > > channel #haskell because I can't concentrate on my work if I have to > > follow the endless discussions in the channel. By the way so far your > > voice seems to be the only one against. I would like to hear what the > > other guys think. > > I would tend to agree with Neil that significant additions to the core > libraries should be proven first as separate packages and integrated > later. I wonder if there's a good case already: The zipper module here has: * A solid theoretical foundation (its a straightforward derivative of a data type) * Sensible API derived from Huet's papers, then implemented and used for Yi, one of the larger Haskell projects * Rich testsuite -- with 100% test coverage And its a derivative of a type in containers, so makes sense to be in containers, no? If not, maybe we need to clarify the process for inclusion in the core lib set. E.g. the above constraints, and "6 months testing as a standalone package" -- Don From david.waern at gmail.com Wed Jun 4 13:54:56 2008 From: david.waern at gmail.com (David Waern) Date: Wed Jun 4 13:47:30 2008 Subject: haddock: record types with partially exported fields In-Reply-To: <483D7D53.4080105@hot.ee> References: <483D7D53.4080105@hot.ee> Message-ID: 2008/5/28 Misha Aizatulin : > P.S. What's the right place to talk about haddock by the way? haskelldoc@haskell.org Thanks for the feature request, will look at it later. David From isaacdupree at charter.net Wed Jun 4 14:26:06 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Wed Jun 4 14:18:40 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <5ab17e790806041014i5624fc7fkcde64aca7472659a@mail.gmail.com> References: <5ab17e790806021157k33ab6a06n982746fe9ccae678@mail.gmail.com> <404396ef0806021505q39ef04e3ib5ba878b967b72e2@mail.gmail.com> <953e0d250806030051g7faffedav5872f9ca39dbe94@mail.gmail.com> <404396ef0806030158g41601671t41843824e51bfc5@mail.gmail.com> <5ab17e790806031415r180985d6u651dd27d1ed6158f@mail.gmail.com> <404396ef0806031423h785aea6k88c893b10af11712@mail.gmail.com> <1212570884.15010.251.camel@localhost> <20080604103920.5865d0c3.Malcolm.Wallace@cs.york.ac.uk> <5ab17e790806041014i5624fc7fkcde64aca7472659a@mail.gmail.com> Message-ID: <4846DE3E.9030001@charter.net> Iavor Diatchki wrote: > Hi, > If this is the consensus, than people that feel this way should write > a document describing the new process so that we know how to > contribute code. +1. unfortunately, I'm not volunteering today > - what is a "core" package > Perhaps, a package that is distributed with GHC? Evidently not -- mtl is probably considered a core package, and, it's not distributed with GHC. Perhaps, a package that is maintained by libraries@haskell.org? > - what constitutes a "significant" change > Not sure how to define this. I would be weary of changes to the > existing functions/types in the APIs of existing modules. But adding > extra functionality? Especially, if---like in the case of > Zipper---the implementation can be more or less computed from an > existing definition in the package (I am referring to the fact that > the zipper is the derivative of Tree, for details you can look at > Conor's paper). > > - what makes code "proven" > Again, not sure how to define this. The code for Zipper has QC > tests that cover it 100%, according to HPC. Proven to be a useful interface, more than proven to be bug-free[*], IMHO. It's easier for us to maintain a package by perfecting its documentation, implementation etc. as a community; but harder to explore large design spaces when an existing solution comes to be felt as inadequate for the purposes it's used for. [*] of course you can't *prove* anything to be bug-free, let's say "demonstrated not to have too many fatal bugs" :-) -Isaac From isaacdupree at charter.net Wed Jun 4 14:29:50 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Wed Jun 4 14:22:24 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <20080604174005.GA19197@scytale.galois.com> References: <4843CB68.5010904@charter.net> <404396ef0806020411v5ef46278gd1ae8ee29c3ce805@mail.gmail.com> <5ab17e790806021157k33ab6a06n982746fe9ccae678@mail.gmail.com> <404396ef0806021505q39ef04e3ib5ba878b967b72e2@mail.gmail.com> <953e0d250806030051g7faffedav5872f9ca39dbe94@mail.gmail.com> <404396ef0806030158g41601671t41843824e51bfc5@mail.gmail.com> <5ab17e790806031415r180985d6u651dd27d1ed6158f@mail.gmail.com> <404396ef0806031423h785aea6k88c893b10af11712@mail.gmail.com> <1212570884.15010.251.camel@localhost> <20080604174005.GA19197@scytale.galois.com> Message-ID: <4846DF1E.1090406@charter.net> Don Stewart wrote: > I wonder if there's a good case already: > > The zipper module here has: > > * A solid theoretical foundation (its a straightforward derivative > of a data type) and seems to go along with that data type, in the places it's used? is that right? > * Sensible API derived from Huet's papers, then implemented and used > for Yi, one of the larger Haskell projects interesting, so Yi would start using the version in `containers` if we put it there? And so would Krasimir's projects? If so, that sounds like a solid user-base... hmm. -Isaac From bulat.ziganshin at gmail.com Wed Jun 4 14:31:34 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Jun 4 14:30:53 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <4846DF1E.1090406@charter.net> References: <4843CB68.5010904@charter.net> <404396ef0806020411v5ef46278gd1ae8ee29c3ce805@mail.gmail.com> <5ab17e790806021157k33ab6a06n982746fe9ccae678@mail.gmail.com> <404396ef0806021505q39ef04e3ib5ba878b967b72e2@mail.gmail.com> <953e0d250806030051g7faffedav5872f9ca39dbe94@mail.gmail.com> <404396ef0806030158g41601671t41843824e51bfc5@mail.gmail.com> <5ab17e790806031415r180985d6u651dd27d1ed6158f@mail.gmail.com> <404396ef0806031423h785aea6k88c893b10af11712@mail.gmail.com> <1212570884.15010.251.camel@localhost> <20080604174005.GA19197@scytale.galois.com> <4846DF1E.1090406@charter.net> Message-ID: <672130534.20080604223134@gmail.com> Hello Isaac, Wednesday, June 4, 2008, 10:29:50 PM, you wrote: > so Yi would start using the version in `containers` if we put it there? > And so would Krasimir's projects? If so, that sounds like a solid > user-base... i wonder how they will use it if containers package is bundled with ghc and used by almost every other library? does this mean that process of Yi installation, for example, will require to recompile every library installed that use containers? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From igloo at earth.li Wed Jun 4 16:21:17 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Jun 4 16:13:54 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <5ab17e790806041014i5624fc7fkcde64aca7472659a@mail.gmail.com> References: <5ab17e790806021157k33ab6a06n982746fe9ccae678@mail.gmail.com> <404396ef0806021505q39ef04e3ib5ba878b967b72e2@mail.gmail.com> <953e0d250806030051g7faffedav5872f9ca39dbe94@mail.gmail.com> <404396ef0806030158g41601671t41843824e51bfc5@mail.gmail.com> <5ab17e790806031415r180985d6u651dd27d1ed6158f@mail.gmail.com> <404396ef0806031423h785aea6k88c893b10af11712@mail.gmail.com> <1212570884.15010.251.camel@localhost> <20080604103920.5865d0c3.Malcolm.Wallace@cs.york.ac.uk> <5ab17e790806041014i5624fc7fkcde64aca7472659a@mail.gmail.com> Message-ID: <20080604202117.GA21658@matrix.chaos.earth.li> On Wed, Jun 04, 2008 at 10:14:59AM -0700, Iavor Diatchki wrote: > > extra functionality? Especially, if---like in the case of > Zipper---the implementation can be more or less computed from an > existing definition in the package (I am referring to the fact that > the zipper is the derivative of Tree, for details you can look at > Conor's paper). I've just skimmed http://citeseer.ist.psu.edu/472190.html The Derivative of a Regular Type is its Type of One-Hole Contexts (Extended Abstract) (2001) Conor McBride Given the way people had been appealing to it, I has assumed that datastructure derivatives were some general thing, but it looks like they are actually just a way of describing a particular concrete implementation of zippers. I'm not even sure how well the theoretical connection applies to the variable branching degree of Data.Tree. Also, it's actually the derivative of Forest, not Tree, right? Which is why toTree can lose information, here the b and c trees: Data.Tree.Zipper> toTree (Loc (Node 'a' []) [Node 'b' []] [Node 'c' []] []) Node {rootLabel = 'a', subForest = []} This feels a little scary to me. Also, I think that technically it doesn't follow the paper, in that it stores the parents in the reverse order. That aside, the fact the datastructure is a derivative doesn't tell us that it is efficient (in fact, it is more efficient because it /isn't/ a straightforward derivative, but reverses the parent order as above), that we have implemented the "right" methods to operate on it, that we have chosen the "best" names for those methods, etc. > - what makes code "proven" > Again, not sure how to define this. The code for Zipper has QC > tests that cover it 100%, according to HPC. The question is more "is it the best interface" than "is the code correct". > Or are we going to > require that it is already used by many people as a separate package, > and then we are going to ask everyone to change their code, so that > they can start using it from the new location? The only change that should be needed is changing the Cabal dependencies (and even that isn't strictly necessary, as you can make an empty zipper package that depends on containers (>= n). > But more to the point though, does anyone have any suggestions about > what may be wrong with the Zipper concretely, rather then the library > process in general? Neil, the sniplet that you posted from the IRC > channel does not give us an idea of what we might want to change. Agreed: It sounds like people who have thought about this in the past have found some design choices; it might be useful if they could explain what they are. > >> I would tend to agree with Neil that significant additions to the core > >> libraries should be proven first as separate packages and integrated > >> later. > > > > +1 I agree too - no matter how much you mark it experimental, people will still complain loudly if you try to change the interface of a module in the "standard" libraries. Thanks Ian From dons at galois.com Wed Jun 4 16:26:55 2008 From: dons at galois.com (Don Stewart) Date: Wed Jun 4 16:19:50 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <20080604202117.GA21658@matrix.chaos.earth.li> References: <404396ef0806021505q39ef04e3ib5ba878b967b72e2@mail.gmail.com> <953e0d250806030051g7faffedav5872f9ca39dbe94@mail.gmail.com> <404396ef0806030158g41601671t41843824e51bfc5@mail.gmail.com> <5ab17e790806031415r180985d6u651dd27d1ed6158f@mail.gmail.com> <404396ef0806031423h785aea6k88c893b10af11712@mail.gmail.com> <1212570884.15010.251.camel@localhost> <20080604103920.5865d0c3.Malcolm.Wallace@cs.york.ac.uk> <5ab17e790806041014i5624fc7fkcde64aca7472659a@mail.gmail.com> <20080604202117.GA21658@matrix.chaos.earth.li> Message-ID: <20080604202655.GI19197@scytale.galois.com> igloo: > On Wed, Jun 04, 2008 at 10:14:59AM -0700, Iavor Diatchki wrote: > > > > extra functionality? Especially, if---like in the case of > > Zipper---the implementation can be more or less computed from an > > existing definition in the package (I am referring to the fact that > > the zipper is the derivative of Tree, for details you can look at > > Conor's paper). > > I've just skimmed http://citeseer.ist.psu.edu/472190.html > The Derivative of a Regular Type is its Type of One-Hole Contexts > (Extended Abstract) (2001) > Conor McBride > > Given the way people had been appealing to it, I has assumed that > datastructure derivatives were some general thing, but it looks like > they are actually just a way of describing a particular concrete > implementation of zippers. I'm not even sure how well the theoretical > connection applies to the variable branching degree of Data.Tree. > > Also, it's actually the derivative of Forest, not Tree, right? Which is > why toTree can lose information, here the b and c trees: > Data.Tree.Zipper> toTree (Loc (Node 'a' []) [Node 'b' []] [Node 'c' []] []) > Node {rootLabel = 'a', subForest = []} > This feels a little scary to me. > > Also, I think that technically it doesn't follow the paper, in that it > stores the parents in the reverse order. > > That aside, the fact the datastructure is a derivative doesn't tell us > that it is efficient (in fact, it is more efficient because it /isn't/ a > straightforward derivative, but reverses the parent order as above), > that we have implemented the "right" methods to operate on it, that we > have chosen the "best" names for those methods, etc. Quite so, the list derivative xmonad uses, for example, taken straight from the Huet paper, data Stack a = Stack { focus :: !a -- focused thing in this set , up :: [a] -- clowns to the left , down :: [a] } -- jokers to the right deriving (Show, Read, Eq) has an integration function, integrate :: Stack a -> [a] integrate (Stack x l r) = reverse l ++ x : r and, e.g. moving around the structure, focusUp (Stack t (l:ls) rs) = Stack l ls (t:rs) focusUp (Stack t [] rs) = Stack x xs [] where (x:xs) = reverse (t:rs) The structure of the type is derived, the implementation of the API is able to make further decisions appropriate to the representation. -- Don From apfelmus at quantentunnel.de Wed Jun 4 17:11:58 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Wed Jun 4 17:04:41 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <20080604202117.GA21658@matrix.chaos.earth.li> References: <5ab17e790806021157k33ab6a06n982746fe9ccae678@mail.gmail.com> <404396ef0806021505q39ef04e3ib5ba878b967b72e2@mail.gmail.com> <953e0d250806030051g7faffedav5872f9ca39dbe94@mail.gmail.com> <404396ef0806030158g41601671t41843824e51bfc5@mail.gmail.com> <5ab17e790806031415r180985d6u651dd27d1ed6158f@mail.gmail.com> <404396ef0806031423h785aea6k88c893b10af11712@mail.gmail.com> <1212570884.15010.251.camel@localhost> <20080604103920.5865d0c3.Malcolm.Wallace@cs.york.ac.uk> <5ab17e790806041014i5624fc7fkcde64aca7472659a@mail.gmail.com> <20080604202117.GA21658@matrix.chaos.earth.li> Message-ID: Ian Lynagh wrote: > I've just skimmed http://citeseer.ist.psu.edu/472190.html > The Derivative of a Regular Type is its Type of One-Hole Contexts > (Extended Abstract) (2001) > Conor McBride > > Given the way people had been appealing to it, I has assumed that > datastructure derivatives were some general thing, but it looks like > they are actually just a way of describing a particular concrete > implementation of zippers. I'm not even sure how well the theoretical > connection applies to the variable branching degree of Data.Tree. This is quite right, the connection between zippers and derivatives is not as straightforward as it seems. First, they are different things. You can obtain a zipper for an inductive data structure type Foo = ? x. F x by differentiating the functor F , but you can't differentiate Foo itself. (I think that the zipper may even depend on the particular choice of F.) Yet, both may coincide; the derivative of type List a = ? x . 1 + (a, x) with respect to a and the zipper for lists are pretty much the same. > Also, I think that technically it doesn't follow the paper, in that it > stores the parents in the reverse order. > > That aside, the fact the datastructure is a derivative doesn't tell us > that it is efficient (in fact, it is more efficient because it /isn't/ a > straightforward derivative, but reverses the parent order as above), > that we have implemented the "right" methods to operate on it, that we > have chosen the "best" names for those methods, etc. Correct, applying the rules of differentiation directly usually does not give the most efficient structure. When differentiating fixed points, one usually ends up with something like type DF a = ? x . T a + (S a, x) which is basically a list of S a that doesn't end with [] but with a value of type T a . Of course, this is isomorphic to type DF' a = ([S a], T a) with the list reversed; but this isomorphism is an optimization. > Also, it's actually the derivative of Forest, not Tree, right? Which is > why toTree can lose information, here the b and c trees: > Data.Tree.Zipper> toTree (Loc (Node 'a' []) [Node 'b' []] [Node 'c' []] []) > Node {rootLabel = 'a', subForest = []} > This feels a little scary to me. Yes. A zipper for a tree would have to carry the value a around. Regards, apfelmus PS: The article in the wikibook http://en.wikibooks.org/wiki/Haskell/Zippers tries to point out the above distinctions. From igloo at earth.li Wed Jun 4 17:36:40 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Jun 4 17:29:15 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: References: <953e0d250806030051g7faffedav5872f9ca39dbe94@mail.gmail.com> <404396ef0806030158g41601671t41843824e51bfc5@mail.gmail.com> <5ab17e790806031415r180985d6u651dd27d1ed6158f@mail.gmail.com> <404396ef0806031423h785aea6k88c893b10af11712@mail.gmail.com> <1212570884.15010.251.camel@localhost> <20080604103920.5865d0c3.Malcolm.Wallace@cs.york.ac.uk> <5ab17e790806041014i5624fc7fkcde64aca7472659a@mail.gmail.com> <20080604202117.GA21658@matrix.chaos.earth.li> Message-ID: <20080604213639.GA4666@matrix.chaos.earth.li> On Wed, Jun 04, 2008 at 11:11:58PM +0200, apfelmus wrote: > Ian Lynagh wrote: > > > >Also, it's actually the derivative of Forest, not Tree, right? Which is > >why toTree can lose information, here the b and c trees: > > Data.Tree.Zipper> toTree (Loc (Node 'a' []) [Node 'b' []] [Node 'c' > > []] []) > > Node {rootLabel = 'a', subForest = []} > >This feels a little scary to me. I should expand on that: I wonder if toTree should return Maybe (Tree a) which returns Nothing if either sibling is non-empty. > Yes. A zipper for a tree would have to carry the value a around. It would actually simplify the datastructure; rather than data TreeLoc a = Loc { tree :: Tree a -- ^ The currently selected tree. , lefts :: Forest a -- ^ Siblings on the left, closest first. , rights :: Forest a -- ^ Siblings on the right, closest first. , parents :: [(Forest a, a, Forest a)] -- ^ The contexts of the parents for this location. } deriving (Read,Show,Eq) we could have just data TreeLoc a = Loc { tree :: Tree a -- ^ The currently selected tree. , parents :: [(Forest a, a, Forest a)] -- ^ The contexts of the parents for this location. } deriving (Read,Show,Eq) where the Forests are now children of the parent nodes, rather than their siblings. The cost is that you now can't represent forests nicely. Thanks Ian From johan.tibell at gmail.com Thu Jun 5 04:18:10 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu Jun 5 04:10:45 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <20080604202117.GA21658@matrix.chaos.earth.li> References: <5ab17e790806021157k33ab6a06n982746fe9ccae678@mail.gmail.com> <953e0d250806030051g7faffedav5872f9ca39dbe94@mail.gmail.com> <404396ef0806030158g41601671t41843824e51bfc5@mail.gmail.com> <5ab17e790806031415r180985d6u651dd27d1ed6158f@mail.gmail.com> <404396ef0806031423h785aea6k88c893b10af11712@mail.gmail.com> <1212570884.15010.251.camel@localhost> <20080604103920.5865d0c3.Malcolm.Wallace@cs.york.ac.uk> <5ab17e790806041014i5624fc7fkcde64aca7472659a@mail.gmail.com> <20080604202117.GA21658@matrix.chaos.earth.li> Message-ID: <90889fe70806050118p26960b69u2344c22f9d83a171@mail.gmail.com> On Wed, Jun 4, 2008 at 10:21 PM, Ian Lynagh wrote: > On Wed, Jun 04, 2008 at 10:14:59AM -0700, Iavor Diatchki wrote: >> - what makes code "proven" >> Again, not sure how to define this. The code for Zipper has QC >> tests that cover it 100%, according to HPC. > > The question is more "is it the best interface" than "is the code > correct". We really need something like the Python community's Python Enhancement Proposals (PEPs) [1] where different design trade-offs, corner cases, performance, etc. can be discussed before something is accepted into core libraries. It think that process has work very well and is probably one of the reasons why Python have such nice (and consistent!) standard libraries. 1. http://www.python.org/dev/peps/ -- Johan From ross at soi.city.ac.uk Thu Jun 5 12:17:39 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Jun 5 12:10:15 2008 Subject: haddock: record types with partially exported fields In-Reply-To: References: <483D7D53.4080105@hot.ee> Message-ID: <20080605161739.GA4187@soi.city.ac.uk> On Wed, Jun 04, 2008 at 07:54:56PM +0200, David Waern wrote: > 2008/5/28 Misha Aizatulin : > > P.S. What's the right place to talk about haddock by the way? > > haskelldoc@haskell.org Could we have Haddock as a component on the GHC trac? It seems approriate, with Haddock 2 so closely tied to GHC. From dons at galois.com Thu Jun 5 16:08:09 2008 From: dons at galois.com (Don Stewart) Date: Thu Jun 5 16:00:59 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <90889fe70806050118p26960b69u2344c22f9d83a171@mail.gmail.com> References: <953e0d250806030051g7faffedav5872f9ca39dbe94@mail.gmail.com> <404396ef0806030158g41601671t41843824e51bfc5@mail.gmail.com> <5ab17e790806031415r180985d6u651dd27d1ed6158f@mail.gmail.com> <404396ef0806031423h785aea6k88c893b10af11712@mail.gmail.com> <1212570884.15010.251.camel@localhost> <20080604103920.5865d0c3.Malcolm.Wallace@cs.york.ac.uk> <5ab17e790806041014i5624fc7fkcde64aca7472659a@mail.gmail.com> <20080604202117.GA21658@matrix.chaos.earth.li> <90889fe70806050118p26960b69u2344c22f9d83a171@mail.gmail.com> Message-ID: <20080605200809.GD19896@scytale.galois.com> johan.tibell: > On Wed, Jun 4, 2008 at 10:21 PM, Ian Lynagh wrote: > > On Wed, Jun 04, 2008 at 10:14:59AM -0700, Iavor Diatchki wrote: > >> - what makes code "proven" > >> Again, not sure how to define this. The code for Zipper has QC > >> tests that cover it 100%, according to HPC. > > > > The question is more "is it the best interface" than "is the code > > correct". > > We really need something like the Python community's Python > Enhancement Proposals (PEPs) [1] where different design trade-offs, > corner cases, performance, etc. can be discussed before something is > accepted into core libraries. It think that process has work very well > and is probably one of the reasons why Python have such nice (and > consistent!) standard libraries. I'd be happy to have anything that helps the process run smoothly. The current approach of mail conversations makes it difficult to determine the result, if there are any objections, I've noticed. -- Don From david.waern at gmail.com Fri Jun 6 05:32:23 2008 From: david.waern at gmail.com (David Waern) Date: Fri Jun 6 05:24:53 2008 Subject: haddock: record types with partially exported fields In-Reply-To: <20080605161739.GA4187@soi.city.ac.uk> References: <483D7D53.4080105@hot.ee> <20080605161739.GA4187@soi.city.ac.uk> Message-ID: 2008/6/5 Ross Paterson : > On Wed, Jun 04, 2008 at 07:54:56PM +0200, David Waern wrote: >> 2008/5/28 Misha Aizatulin : >> > P.S. What's the right place to talk about haddock by the way? >> >> haskelldoc@haskell.org > > Could we have Haddock as a component on the GHC trac? > > It seems approriate, with Haddock 2 so closely tied to GHC. I'd rather see Haddock less tied to GHC, and for it to have it's own trac. But let's see what happens with the GHC documentation problem. If Haddock has to be bundled with GHC, it makes more sense for it to be in the GHC trac. David From duncan.coutts at worc.ox.ac.uk Fri Jun 6 14:45:38 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Jun 6 14:34:27 2008 Subject: hackage, package list, trac, some suggestions/questions In-Reply-To: <1212180723.15010.46.camel@localhost> References: <1212180723.15010.46.camel@localhost> Message-ID: <1212777938.15010.384.camel@localhost> On Fri, 2008-05-30 at 21:52 +0100, Duncan Coutts wrote: > On Fri, 2008-05-30 at 15:23 +0100, Claus Reinke wrote: > > hope this is the right list for hackage issues?-) > > > > 1. hackage trac does not seem to have a "register" option > > (compare hackage trac with ghc trac). individual logins > > are nice because: > > - gives individual rather than anonymous reporters > > - one place less to support spam email harvesters > > (account name instead of full email address) > > - "register" is always there, hence easy to find, unlike > > the hint hidden on the trac home page that hackage > > is still abusing the haskell' trac.. (i had started this > > email before i found that hint;-) > > We used to have that and got horribly spammed. Apparently for the ghc > trac they've worked out how to do that without getting spammed so > presumably we could do the same. Now done. Duncan From cdsmith at gmail.com Fri Jun 6 20:52:47 2008 From: cdsmith at gmail.com (Chris Smith) Date: Fri Jun 6 20:52:37 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries References: <5ab17e790806021157k33ab6a06n982746fe9ccae678@mail.gmail.com> <404396ef0806021505q39ef04e3ib5ba878b967b72e2@mail.gmail.com> <953e0d250806030051g7faffedav5872f9ca39dbe94@mail.gmail.com> <404396ef0806030158g41601671t41843824e51bfc5@mail.gmail.com> <5ab17e790806031415r180985d6u651dd27d1ed6158f@mail.gmail.com> <404396ef0806031423h785aea6k88c893b10af11712@mail.gmail.com> <1212570884.15010.251.camel@localhost> <20080604103920.5865d0c3.Malcolm.Wallace@cs.york.ac.uk> <5ab17e790806041014i5624fc7fkcde64aca7472659a@mail.gmail.com> Message-ID: Iavor Diatchki wrote: > Or are we going to > require that it is already used by many people as a separate package, > and then we are going to ask everyone to change their code, so that they > can start using it from the new location? As an aside, I don't see why this would require anyone to change their code. So long as people choose good module names, the movement of some module from one package to another at most changes a Makefile or .cabal file. I actually rather like this about Haskell as it currently exists; third-party packages don't have to be isolated behemoths walled off by namespace issues. In fact, there are good examples of cases where external packages define modules in Data.* module hierarchy with perfectly logical names. The code is then entirely independent of packaging concerns. -- Chris From iavor.diatchki at gmail.com Sat Jun 7 13:20:10 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sat Jun 7 13:12:39 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: References: <953e0d250806030051g7faffedav5872f9ca39dbe94@mail.gmail.com> <404396ef0806030158g41601671t41843824e51bfc5@mail.gmail.com> <5ab17e790806031415r180985d6u651dd27d1ed6158f@mail.gmail.com> <404396ef0806031423h785aea6k88c893b10af11712@mail.gmail.com> <1212570884.15010.251.camel@localhost> <20080604103920.5865d0c3.Malcolm.Wallace@cs.york.ac.uk> <5ab17e790806041014i5624fc7fkcde64aca7472659a@mail.gmail.com> Message-ID: <5ab17e790806071020t7f953682pd8ecd208a0e47eec@mail.gmail.com> Hello, When I said "code" I was referring to the build system as well as the Haskell code. "Just changing a Makefile" is not a trivial issue, and even if it was, it would still be a change that somebody would have to make in all packages that depend on the code (and possibly, in a bunch of packages that depend on _these_ packages to chanage version numbers in dependecies). And how would you setup the dependencies in the new code? You would either have to use an extra flag, just for the one Zipper module, or you would need to have some kind of disjunction of dependencies. Something like: (containers >= X) or (containers > Y and containers < X and Zipper) where X is the new code got moved to containers, and Y is a known good version of containers. Does Cabal even support this kind of thing? Of course, things like that are unavoidable in general, the question is how often do we want to ask programmers to deal with this kind of thing. I think that it is completely unwarranted in the case of the single ZIpper module. -Iavor On Fri, Jun 6, 2008 at 5:52 PM, Chris Smith wrote: > Iavor Diatchki wrote: >> Or are we going to >> require that it is already used by many people as a separate package, >> and then we are going to ask everyone to change their code, so that they >> can start using it from the new location? > > As an aside, I don't see why this would require anyone to change their > code. So long as people choose good module names, the movement of some > module from one package to another at most changes a Makefile or .cabal > file. I actually rather like this about Haskell as it currently exists; > third-party packages don't have to be isolated behemoths walled off by > namespace issues. In fact, there are good examples of cases where > external packages define modules in Data.* module hierarchy with > perfectly logical names. The code is then entirely independent of > packaging concerns. > > -- > Chris > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From iavor.diatchki at gmail.com Sat Jun 7 14:05:56 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sat Jun 7 13:58:22 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <20080604213639.GA4666@matrix.chaos.earth.li> References: <953e0d250806030051g7faffedav5872f9ca39dbe94@mail.gmail.com> <5ab17e790806031415r180985d6u651dd27d1ed6158f@mail.gmail.com> <404396ef0806031423h785aea6k88c893b10af11712@mail.gmail.com> <1212570884.15010.251.camel@localhost> <20080604103920.5865d0c3.Malcolm.Wallace@cs.york.ac.uk> <5ab17e790806041014i5624fc7fkcde64aca7472659a@mail.gmail.com> <20080604202117.GA21658@matrix.chaos.earth.li> <20080604213639.GA4666@matrix.chaos.earth.li> Message-ID: <5ab17e790806071105u13646c04ycc146a360ed5d28f@mail.gmail.com> Hi Ian, Thanks for discussing the actual Zipper! On Wed, Jun 4, 2008 at 2:36 PM, Ian Lynagh wrote: > On Wed, Jun 04, 2008 at 11:11:58PM +0200, apfelmus wrote: >> > Data.Tree.Zipper> toTree (Loc (Node 'a' []) [Node 'b' []] [Node 'c' >> > []] []) >> > Node {rootLabel = 'a', subForest = []} >> >This feels a little scary to me. > > I should expand on that: I wonder if toTree should return > Maybe (Tree a) > which returns Nothing if either sibling is non-empty. The idea is that "toTree" computes the tree that contains the current location. It makes no calims about this being the only tree in the forest. I think it is useful to have such a function. The function "toForest" computes the entire forest. You can always get the "Maybe" version by examining the result of "toForest", but if you think that it would be useful, we could also add another function to do it (perhaps it belongs to Tree: forestToTree?) > It would actually simplify the datastructure; rather than ... > we could have just > > data TreeLoc a = Loc > { tree :: Tree a -- ^ The currently selected tree. > , parents :: [(Forest a, a, Forest a)] > -- ^ The contexts of the parents for this location. > } deriving (Read,Show,Eq) > > where the Forests are now children of the parent nodes, rather than > their siblings. The cost is that you now can't represent forests nicely. Yeah, this is nice. I think that it would be good to support working with forests though. While we are on questions of API, currently the insertion functions of the Zipper make the inserted tree be the current tree. It is also easy to have functions that insert to the left or to the right but don't change the current tree. What do you think? -Iavor From kr.angelov at gmail.com Sun Jun 8 11:30:34 2008 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Sun Jun 8 11:22:57 2008 Subject: Readline readHistory & writeHistory API broken Message-ID: The current readHistory and writeHistory bindings are defined as: -- |Read in a history file. Returns 'False' on failure -- (for example, if the file does not exist). readHistory :: FilePath -- ^ The file to read (if null, read ~\/.history) -> IO Bool readHistory fp = do ok <- withCString fp read_history return (ok==0) foreign import ccall unsafe read_history :: Ptr CChar -> IO CInt -- |Write out a history file. Returns 'False' if there was a problem writing the file. writeHistory :: FilePath -- ^ The file to write (if null, write ~\/.history) -> IO Bool writeHistory fp = do ok <- withCString fp write_history return (ok==0) foreign import ccall unsafe write_history :: Ptr CChar -> IO CInt Note the comments "(if null, write ~/.history)"! This is supported in the original C API but in Haskell the filepath cannot be null. In the best case it can be empty string. Either the type signatures have to be changed to accept (Maybe FilePath) or the comments have to be changed because the Haskell binding currently doesn't support this functionality. Comments? I hope that this will not start another endless discussion. Regards, Krasimir From avatar at hot.ee Sun Jun 8 15:33:10 2008 From: avatar at hot.ee (Misha Aizatulin) Date: Sun Jun 8 15:25:44 2008 Subject: Feature request: more transparency for Data.Graph.Inductive.NodeMap Message-ID: <484C33F6.3010504@hot.ee> hello, would it be possible to add functions to NodeMap for inspecting the contents of the map? I would be particularly interested in a function like toList :: NodeMap a -> [LNode a] If I use a node map m to construct a graph g, then of course (labNodes g) would achieve the same as (toList m), but if I later transform the labels of the graph, say using nmap, then I cannot do it anymore - the connection between old label values and nodes is still a valuable piece of information, but I cannot access it. Cheers, Misha From dons at galois.com Sun Jun 8 16:17:47 2008 From: dons at galois.com (Don Stewart) Date: Sun Jun 8 16:10:11 2008 Subject: Feature request: more transparency for Data.Graph.Inductive.NodeMap In-Reply-To: <484C33F6.3010504@hot.ee> References: <484C33F6.3010504@hot.ee> Message-ID: <20080608201747.GB18015@scytale.galois.com> avatar: > hello, > > would it be possible to add functions to NodeMap for inspecting the > contents of the map? I would be particularly interested in a function like > toList :: NodeMap a -> [LNode a] > > If I use a node map m to construct a graph g, then of course > (labNodes g) would achieve the same as (toList m), but if I later > transform the labels of the graph, say using nmap, then I cannot do it > anymore - the connection between old label values and nodes is still a > valuable piece of information, but I cannot access it. > > Cheers, > Misha The fgl library is in bad need of a maintainer, so any patches here would be welcome. If you'd like to start documenting things in haddock, that would also be great. So, in summary, if you want something in fgl, submit a patch. -- Don From igloo at earth.li Sun Jun 8 16:37:54 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Jun 8 16:30:18 2008 Subject: Feature request: more transparency for Data.Graph.Inductive.NodeMap In-Reply-To: <20080608201747.GB18015@scytale.galois.com> References: <484C33F6.3010504@hot.ee> <20080608201747.GB18015@scytale.galois.com> Message-ID: <20080608203754.GA14379@matrix.chaos.earth.li> On Sun, Jun 08, 2008 at 01:17:47PM -0700, Donald Bruce Stewart wrote: > > The fgl library is in bad need of a maintainer According to the cabal file, Martin Erwig is the maintainer. For an old, stablish package he's pushed patches reasonably recently (Feb 2008). Thanks Ian From igloo at earth.li Sun Jun 8 16:54:12 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Jun 8 16:46:34 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <5ab17e790806071105u13646c04ycc146a360ed5d28f@mail.gmail.com> References: <5ab17e790806031415r180985d6u651dd27d1ed6158f@mail.gmail.com> <404396ef0806031423h785aea6k88c893b10af11712@mail.gmail.com> <1212570884.15010.251.camel@localhost> <20080604103920.5865d0c3.Malcolm.Wallace@cs.york.ac.uk> <5ab17e790806041014i5624fc7fkcde64aca7472659a@mail.gmail.com> <20080604202117.GA21658@matrix.chaos.earth.li> <20080604213639.GA4666@matrix.chaos.earth.li> <5ab17e790806071105u13646c04ycc146a360ed5d28f@mail.gmail.com> Message-ID: <20080608205412.GB14379@matrix.chaos.earth.li> On Sat, Jun 07, 2008 at 11:05:56AM -0700, Iavor Diatchki wrote: > > What do you think? I think that before semi-freezing the API, it would be good to get some more experience with the library so that these questions are easier to answer. Thanks Ian From iavor.diatchki at gmail.com Sun Jun 8 21:40:48 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sun Jun 8 21:33:10 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <20080608205412.GB14379@matrix.chaos.earth.li> References: <5ab17e790806031415r180985d6u651dd27d1ed6158f@mail.gmail.com> <1212570884.15010.251.camel@localhost> <20080604103920.5865d0c3.Malcolm.Wallace@cs.york.ac.uk> <5ab17e790806041014i5624fc7fkcde64aca7472659a@mail.gmail.com> <20080604202117.GA21658@matrix.chaos.earth.li> <20080604213639.GA4666@matrix.chaos.earth.li> <5ab17e790806071105u13646c04ycc146a360ed5d28f@mail.gmail.com> <20080608205412.GB14379@matrix.chaos.earth.li> Message-ID: <5ab17e790806081840o2a929fbah9880f3342ff57182@mail.gmail.com> Hi, Well, it is clear that the Haskell community (as represented by the few vocal participants in this discussion) is not interested in having a zipper module in the containers package at this point in time. I am not sure of the technical reasons for that, but my understanding is that the general concern is that a lack of experience of working with zippers has caused some uncertainty about the API of the library. To solve this problem it was suggested that the zipper "library" should be distributed as a separate package. In the previous emails I explained why I think that this is a bad idea, but it would appear that I am in the minority. To avoid having the code get lost, I have created a repository, so that interested parties can continue using/improving the code (yes, it is also a cabal package :-). The repository is available here: git://github.com/yav/haskell-zipper.git -Iavor PS: By the way, I was really impressed with github---it is very easy to start new projects and it offers a number of very nice features. On Sun, Jun 8, 2008 at 1:54 PM, Ian Lynagh wrote: > On Sat, Jun 07, 2008 at 11:05:56AM -0700, Iavor Diatchki wrote: >> >> What do you think? > > I think that before semi-freezing the API, it would be good to get some > more experience with the library so that these questions are easier to > answer. > > > Thanks > Ian > > From dons at galois.com Sun Jun 8 21:44:32 2008 From: dons at galois.com (Don Stewart) Date: Sun Jun 8 21:36:56 2008 Subject: Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <5ab17e790806081840o2a929fbah9880f3342ff57182@mail.gmail.com> References: <1212570884.15010.251.camel@localhost> <20080604103920.5865d0c3.Malcolm.Wallace@cs.york.ac.uk> <5ab17e790806041014i5624fc7fkcde64aca7472659a@mail.gmail.com> <20080604202117.GA21658@matrix.chaos.earth.li> <20080604213639.GA4666@matrix.chaos.earth.li> <5ab17e790806071105u13646c04ycc146a360ed5d28f@mail.gmail.com> <20080608205412.GB14379@matrix.chaos.earth.li> <5ab17e790806081840o2a929fbah9880f3342ff57182@mail.gmail.com> Message-ID: <20080609014432.GH18376@scytale.galois.com> iavor.diatchki: > I have created a repository, so that interested > parties can continue using/improving the code (yes, it is also a cabal > package :-). The repository is available here: > git://github.com/yav/haskell-zipper.git If its ready to go, perhaps upload it to hackage? -- Don From avatar at hot.ee Mon Jun 9 17:35:02 2008 From: avatar at hot.ee (Misha Aizatulin) Date: Mon Jun 9 17:27:30 2008 Subject: installing non-haskell binaries with cabal Message-ID: <484DA206.9020507@hot.ee> hello, I would like to distribute a shell script as part of my haskell project. How can I tell cabal to install the script as an executable? Cheers, Misha From avatar at hot.ee Mon Jun 9 18:17:53 2008 From: avatar at hot.ee (Misha Aizatulin) Date: Mon Jun 9 18:10:23 2008 Subject: Feature request: more transparency for Data.Graph.Inductive.NodeMap In-Reply-To: <20080608201747.GB18015@scytale.galois.com> References: <484C33F6.3010504@hot.ee> <20080608201747.GB18015@scytale.galois.com> Message-ID: <484DAC11.8060902@hot.ee> Don Stewart wrote: > So, in summary, if you want something in fgl, submit a patch. ok, here is a patch, a copy is being sent to Martin Erwig. Cheers, Misha -------------- next part -------------- New patches: [NodeMap.toList Misha Aizatulin **20080609220317 See http://thread.gmane.org/gmane.comp.lang.haskell.libraries/9221 ] { hunk ./Data/Graph/Inductive/NodeMap.hs 8 + -- ** Map Inspection + toList, hunk ./Data/Graph/Inductive/NodeMap.hs 47 +toList :: (Ord a) => NodeMap a -> [LNode a] +toList = P.map swap . fmToList . map where + swap (a, b) = (b, a) + hunk ./fgl.cabal 10 +build-type: Simple } Context: [TAG 2008-06-06 Ian Lynagh **20080605235619] Patch bundle hash: a066e6d1085d3672195a26b81e3778b212a3e58b From duncan.coutts at worc.ox.ac.uk Mon Jun 9 18:36:19 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Jun 9 18:24:44 2008 Subject: installing non-haskell binaries with cabal In-Reply-To: <484DA206.9020507@hot.ee> References: <484DA206.9020507@hot.ee> Message-ID: <1213050979.15010.456.camel@localhost> On Mon, 2008-06-09 at 23:35 +0200, Misha Aizatulin wrote: > hello, > > I would like to distribute a shell script as part of my haskell > project. How can I tell cabal to install the script as an executable? At the moment there is no easy way of doing that. It can be installed as a data file pretty easily but not into the $bindir. You'd have to write a custom Setup.hs script and change the postInst hook. Use LocalBuildInfo.absoluteInstallDirs to get the bindir. Duncan From gwern0 at gmail.com Mon Jun 9 19:09:13 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Mon Jun 9 19:01:53 2008 Subject: installing non-haskell binaries with cabal In-Reply-To: <1213050979.15010.456.camel@localhost> References: <484DA206.9020507@hot.ee> <1213050979.15010.456.camel@localhost> Message-ID: <20080609230913.GA21789@craft> On 2008.06.09 23:36:19 +0100, Duncan Coutts scribbled 0.5K characters: > > On Mon, 2008-06-09 at 23:35 +0200, Misha Aizatulin wrote: > > hello, > > > > I would like to distribute a shell script as part of my haskell > > project. How can I tell cabal to install the script as an executable? > > At the moment there is no easy way of doing that. It can be installed as > a data file pretty easily but not into the $bindir. > > You'd have to write a custom Setup.hs script and change the postInst > hook. Use LocalBuildInfo.absoluteInstallDirs to get the bindir. > > Duncan And of course, at that point, you'd be better off just writing the script in Haskell. (Seriously, I had to do that for the Roguestar packages. It was hardly any trouble at all - Haskell is a better scripting language than I think people give it credit for.) -- gwern SADRS CTP Dateline Mac-10 Alex Sears Ceridian botux Artful industrial -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/libraries/attachments/20080609/27745490/attachment.bin From dons at galois.com Mon Jun 9 19:22:04 2008 From: dons at galois.com (Don Stewart) Date: Mon Jun 9 19:14:30 2008 Subject: installing non-haskell binaries with cabal In-Reply-To: <20080609230913.GA21789@craft> References: <484DA206.9020507@hot.ee> <1213050979.15010.456.camel@localhost> <20080609230913.GA21789@craft> Message-ID: <20080609232204.GH25378@scytale.galois.com> gwern0: > On 2008.06.09 23:36:19 +0100, Duncan Coutts scribbled 0.5K characters: > > > > On Mon, 2008-06-09 at 23:35 +0200, Misha Aizatulin wrote: > > > hello, > > > > > > I would like to distribute a shell script as part of my haskell > > > project. How can I tell cabal to install the script as an executable? > > > > At the moment there is no easy way of doing that. It can be installed as > > a data file pretty easily but not into the $bindir. > > > > You'd have to write a custom Setup.hs script and change the postInst > > hook. Use LocalBuildInfo.absoluteInstallDirs to get the bindir. > > > > Duncan > > And of course, at that point, you'd be better off just writing the script in Haskell. > > (Seriously, I had to do that for the Roguestar packages. It was hardly > any trouble at all - Haskell is a better scripting language than I > think people give it credit for.) I'd agree here. It probably is easier to rewrite it in Haskell (just use system everywhere), and keep easy distribution via cabal-install. -- Don From erwig at eecs.oregonstate.edu Mon Jun 9 18:42:44 2008 From: erwig at eecs.oregonstate.edu (Martin Erwig) Date: Mon Jun 9 20:42:20 2008 Subject: Feature request: more transparency for Data.Graph.Inductive.NodeMap References: <484C33F6.3010504@hot.ee> <20080608201747.GB18015@scytale.galois.com> <20080608203754.GA14379@matrix.chaos.earth.li> Message-ID: Ian Lynagh earth.li> writes: > > On Sun, Jun 08, 2008 at 01:17:47PM -0700, Donald Bruce Stewart wrote: > > > > The fgl library is in bad need of a maintainer > > According to the cabal file, Martin Erwig is the maintainer. For an old, > stablish package he's pushed patches reasonably recently (Feb 2008). Both of you are right. I am not working actively on further FGL developments. Every now and then I receive new implementations or bug fixes, and also, of course, feature requests. I try to accommodate requests as much as possible, although I have refused requests for more radical restructuring (mostly because it would break existing code). So if there is an individual or a group of people who would like to "adopt" the FGL, that would be in principle fine with me. I don't know where the right place for such a discussion would be. -- Martin From lemming at henning-thielemann.de Tue Jun 10 06:32:00 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Jun 10 06:24:20 2008 Subject: installing non-haskell binaries with cabal In-Reply-To: <20080609232204.GH25378@scytale.galois.com> References: <484DA206.9020507@hot.ee> <1213050979.15010.456.camel@localhost> <20080609230913.GA21789@craft> <20080609232204.GH25378@scytale.galois.com> Message-ID: On Mon, 9 Jun 2008, Don Stewart wrote: > gwern0: >> >> And of course, at that point, you'd be better off just writing the script in Haskell. >> >> (Seriously, I had to do that for the Roguestar packages. It was hardly >> any trouble at all - Haskell is a better scripting language than I >> think people give it credit for.) > > I'd agree here. It probably is easier to rewrite it in Haskell (just use > system everywhere), and keep easy distribution via cabal-install. I think Haskell code is also more portable than bash code. From avatar at hot.ee Tue Jun 10 08:42:19 2008 From: avatar at hot.ee (Misha Aizatulin) Date: Tue Jun 10 08:34:47 2008 Subject: installing non-haskell binaries with cabal In-Reply-To: <20080609230913.GA21789@craft> References: <484DA206.9020507@hot.ee> <1213050979.15010.456.camel@localhost> <20080609230913.GA21789@craft> Message-ID: <484E76AB.20508@hot.ee> Gwern Branwen wrote: > And of course, at that point, you'd be better off just writing the script in Haskell. I'd still be happy if cabal better supported heterogeneous projects, where some parts are written in another language. Count it as my feature request - seems to be be quite easy as far as executable installation is concerned. There are many reasons to write some utilities in another language, like * legacy code * a two-liner shell script is small, where an equivalent compiled haskell code may be hundreds of kbs (looks like cabal doesn't allow to install haskell scripts, only compiled code) * my editor does syntax highlighting for pure shell scripts but not for shell scripts wrapped in haskell * love for pipes, subshells, perl regular expressions, etc. If you want an example, look at ghc: it comes with perl scripts. Cheers, Misha From jonathanccast at fastmail.fm Mon Jun 9 19:37:55 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Tue Jun 10 22:34:10 2008 Subject: installing non-haskell binaries with cabal In-Reply-To: <20080609232204.GH25378@scytale.galois.com> References: <484DA206.9020507@hot.ee> <1213050979.15010.456.camel@localhost> <20080609230913.GA21789@craft> <20080609232204.GH25378@scytale.galois.com> Message-ID: <1213054675.6505.2.camel@jonathans-macbook> On Mon, 2008-06-09 at 16:22 -0700, Don Stewart wrote: > gwern0: > > On 2008.06.09 23:36:19 +0100, Duncan Coutts > scribbled 0.5K characters: > > > > > > On Mon, 2008-06-09 at 23:35 +0200, Misha Aizatulin wrote: > > > > hello, > > > > > > > > I would like to distribute a shell script as part of my haskell > > > > project. How can I tell cabal to install the script as an > executable? > > > > > > At the moment there is no easy way of doing that. It can be > installed as > > > a data file pretty easily but not into the $bindir. > > > > > > You'd have to write a custom Setup.hs script and change the > postInst > > > hook. Use LocalBuildInfo.absoluteInstallDirs to get the bindir. > > > > > > Duncan > > > > And of course, at that point, you'd be better off just writing the > script in Haskell. > > > > (Seriously, I had to do that for the Roguestar packages. It was > hardly > > any trouble at all - Haskell is a better scripting language than I > > think people give it credit for.) > > I'd agree here. It probably is easier to rewrite it in Haskell (just > use > system everywhere), and keep easy distribution via cabal-install. Yikes. Every time I learn something new about Cabal, it's /always/ some new limitation, never a new feature. Are there any plans to someday permit doing things with Cabal the Cabal developers haven't added specific code for yet? jcc From duncan.coutts at worc.ox.ac.uk Wed Jun 11 06:08:51 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jun 11 05:57:03 2008 Subject: installing non-haskell binaries with cabal In-Reply-To: <1213054675.6505.2.camel@jonathans-macbook> References: <484DA206.9020507@hot.ee> <1213050979.15010.456.camel@localhost> <20080609230913.GA21789@craft> <20080609232204.GH25378@scytale.galois.com> <1213054675.6505.2.camel@jonathans-macbook> Message-ID: <1213178931.15010.481.camel@localhost> On Mon, 2008-06-09 at 16:37 -0700, Jonathan Cast wrote: > On Mon, 2008-06-09 at 16:22 -0700, Don Stewart wrote: > > gwern0: > > > And of course, at that point, you'd be better off just writing the > > script in Haskell. > > > > > > (Seriously, I had to do that for the Roguestar packages. It was > > hardly > > > any trouble at all - Haskell is a better scripting language than I > > > think people give it credit for.) > > > > I'd agree here. It probably is easier to rewrite it in Haskell (just > > use system everywhere), and keep easy distribution via cabal-install. > > Yikes. Every time I learn something new about Cabal, it's /always/ some > new limitation, never a new feature. Are there any plans to someday > permit doing things with Cabal the Cabal developers haven't added > specific code for yet? All these things are already possible (if not easy) using custom code in the Setup.hs script and/or using a ./configure script. Duncan From igloo at earth.li Wed Jun 11 07:07:20 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Jun 11 06:59:33 2008 Subject: haddock: record types with partially exported fields In-Reply-To: References: <483D7D53.4080105@hot.ee> <20080605161739.GA4187@soi.city.ac.uk> Message-ID: <20080611110720.GA15187@matrix.chaos.earth.li> On Fri, Jun 06, 2008 at 11:32:23AM +0200, David Waern wrote: > 2008/6/5 Ross Paterson : > > On Wed, Jun 04, 2008 at 07:54:56PM +0200, David Waern wrote: > >> 2008/5/28 Misha Aizatulin : > >> > P.S. What's the right place to talk about haddock by the way? > >> > >> haskelldoc@haskell.org > > > > Could we have Haddock as a component on the GHC trac? > > > > It seems approriate, with Haddock 2 so closely tied to GHC. > > I'd rather see Haddock less tied to GHC, and for it to have it's own > trac. But let's see what happens with the GHC documentation problem. > If Haddock has to be bundled with GHC, it makes more sense for it to > be in the GHC trac. If you do want haddock to have its own trac instance then you can now create one on community, as described here: http://community.haskell.org/admin/using_project.html#trac Thanks Ian From igloo at earth.li Wed Jun 11 07:19:37 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Jun 11 07:11:51 2008 Subject: Feature request: more transparency for Data.Graph.Inductive.NodeMap In-Reply-To: References: <484C33F6.3010504@hot.ee> <20080608201747.GB18015@scytale.galois.com> <20080608203754.GA14379@matrix.chaos.earth.li> Message-ID: <20080611111937.GA15388@matrix.chaos.earth.li> On Mon, Jun 09, 2008 at 10:42:44PM +0000, Martin Erwig wrote: > Ian Lynagh earth.li> writes: > > > > On Sun, Jun 08, 2008 at 01:17:47PM -0700, Donald Bruce Stewart wrote: > > > > > > The fgl library is in bad need of a maintainer > > > > According to the cabal file, Martin Erwig is the maintainer. For an old, > > stablish package he's pushed patches reasonably recently (Feb 2008). > > Both of you are right. I am not working actively on further FGL developments. > Every now and then I receive new implementations or bug fixes, and also, > of course, feature requests. I try to accommodate requests as much as > possible, although I have refused requests for more radical restructuring > (mostly because it would break existing code). > > So if there is an individual or a group of people who would like to "adopt" > the FGL, that would be in principle fine with me. I don't know where the > right place for such a discussion would be. libraries@ or haskell@ and HWN are the places that make sense to ask for maintainer volunteers IMO. In the mean time, if you don't have time to deal with submitted patches etc at the moment then you could set the maintainer to be libraries@haskell.org. Thanks Ian From david.waern at gmail.com Wed Jun 11 07:29:20 2008 From: david.waern at gmail.com (David Waern) Date: Wed Jun 11 07:21:35 2008 Subject: haddock: record types with partially exported fields In-Reply-To: <20080611110720.GA15187@matrix.chaos.earth.li> References: <483D7D53.4080105@hot.ee> <20080605161739.GA4187@soi.city.ac.uk> <20080611110720.GA15187@matrix.chaos.earth.li> Message-ID: 2008/6/11 Ian Lynagh : > If you do want haddock to have its own trac instance then you can now > create one on community, as described here: > http://community.haskell.org/admin/using_project.html#trac Ah, that's great! Didn't know that trac support have been added to community. Does anyone else have a preference of where to keep the Haddock trac? Simon M? David From igloo at earth.li Wed Jun 11 07:34:47 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Jun 11 07:27:02 2008 Subject: Readline readHistory & writeHistory API broken In-Reply-To: References: Message-ID: <20080611113447.GB15388@matrix.chaos.earth.li> On Sun, Jun 08, 2008 at 05:30:34PM +0200, Krasimir Angelov wrote: > > Note the comments "(if null, write ~/.history)"! This is supported in > the original C API but in Haskell the filepath cannot be null. In the > best case it can be empty string. Either the type signatures have to > be changed to accept (Maybe FilePath) or the comments have to be > changed because the Haskell binding currently doesn't support this > functionality. If writing to ~/.history is useful then Maybe FilePath makes sense to me, as ~/.history is a bit fiddly to work out yourself. However, it doesn't sound that useful to me, as then all applications would trample over each other. If you want to propose that it uses Maybe FilePath then you'll need to follow http://www.haskell.org/haskellwiki/Library_submissions; otherwise I'll just fix the comments. Thanks Ian From kr.angelov at gmail.com Wed Jun 11 08:04:29 2008 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Wed Jun 11 07:56:43 2008 Subject: Readline readHistory & writeHistory API broken In-Reply-To: <20080611113447.GB15388@matrix.chaos.earth.li> References: <20080611113447.GB15388@matrix.chaos.earth.li> Message-ID: Just fixing the comments is also fine for me. I personally use another file name. On 6/11/08, Ian Lynagh wrote: > On Sun, Jun 08, 2008 at 05:30:34PM +0200, Krasimir Angelov wrote: > > > > Note the comments "(if null, write ~/.history)"! This is supported in > > the original C API but in Haskell the filepath cannot be null. In the > > best case it can be empty string. Either the type signatures have to > > be changed to accept (Maybe FilePath) or the comments have to be > > changed because the Haskell binding currently doesn't support this > > functionality. > > If writing to ~/.history is useful then Maybe FilePath makes sense to > me, as ~/.history is a bit fiddly to work out yourself. > > However, it doesn't sound that useful to me, as then all applications > would trample over each other. > > If you want to propose that it uses Maybe FilePath then you'll need to > follow http://www.haskell.org/haskellwiki/Library_submissions; otherwise > I'll just fix the comments. > > > Thanks > Ian > > From marlowsd at gmail.com Wed Jun 11 00:22:28 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jun 11 08:14:46 2008 Subject: haddock: record types with partially exported fields In-Reply-To: References: <483D7D53.4080105@hot.ee> <20080605161739.GA4187@soi.city.ac.uk> <20080611110720.GA15187@matrix.chaos.earth.li> Message-ID: <484F5304.3080603@gmail.com> David Waern wrote: > 2008/6/11 Ian Lynagh : >> If you do want haddock to have its own trac instance then you can now >> create one on community, as described here: >> http://community.haskell.org/admin/using_project.html#trac > > Ah, that's great! Didn't know that trac support have been added to community. > > Does anyone else have a preference of where to keep the Haddock trac? Simon M? By all means go ahead and create one on community. As you know in the past I've been in favour of keeping things lightweight for Haddock (i.e. a TODO list in the darcs repo), but since you're doing the maintenance these days, it's entirely up to you. Cheers, Simon From jonathanccast at fastmail.fm Wed Jun 11 09:41:37 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Jun 11 09:33:51 2008 Subject: installing non-haskell binaries with cabal In-Reply-To: <1213178931.15010.481.camel@localhost> References: <484DA206.9020507@hot.ee> <1213050979.15010.456.camel@localhost> <20080609230913.GA21789@craft> <20080609232204.GH25378@scytale.galois.com> <1213054675.6505.2.camel@jonathans-macbook> <1213178931.15010.481.camel@localhost> Message-ID: <1213191697.6318.4.camel@jonathans-macbook> On Wed, 2008-06-11 at 11:08 +0100, Duncan Coutts wrote: > On Mon, 2008-06-09 at 16:37 -0700, Jonathan Cast wrote: > > On Mon, 2008-06-09 at 16:22 -0700, Don Stewart wrote: > > > gwern0: > > > > And of course, at that point, you'd be better off just writing the > > > script in Haskell. > > > > > > > > (Seriously, I had to do that for the Roguestar pa