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 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. I assume the claim above about cabal-install failing to install such a package is incorrect, right? Beyond which, to paraphrase what I tell my boss at work, I can get Setup.lhs to do anything I want, it's written in a Turing-complete language. But I'd rather not use a tool I'm going to have to fight. jcc From ross at soi.city.ac.uk Wed Jun 11 09:57:53 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Jun 11 09:50:08 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: <20080611135753.GA10342@soi.city.ac.uk> On Wed, Jun 11, 2008 at 01:29:20PM +0200, 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? I don't mind where it is, just that there is one. From igloo at earth.li Wed Jun 11 10:05:33 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Jun 11 09:57:47 2008 Subject: haddock: record types with partially exported fields In-Reply-To: <20080611135753.GA10342@soi.city.ac.uk> References: <483D7D53.4080105@hot.ee> <20080605161739.GA4187@soi.city.ac.uk> <20080611110720.GA15187@matrix.chaos.earth.li> <20080611135753.GA10342@soi.city.ac.uk> Message-ID: <20080611140533.GA9133@matrix.chaos.earth.li> On Wed, Jun 11, 2008 at 02:57:53PM +0100, Ross Paterson wrote: > On Wed, Jun 11, 2008 at 01:29:20PM +0200, 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? I'd prefer it to be separate, on balance. Thanks Ian From droundy at darcs.net Wed Jun 11 13:17:39 2008 From: droundy at darcs.net (David Roundy) Date: Wed Jun 11 13:09:56 2008 Subject: installing non-haskell binaries with cabal In-Reply-To: <1213191697.6318.4.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> <1213178931.15010.481.camel@localhost> <1213191697.6318.4.camel@jonathans-macbook> Message-ID: <20080611171739.GD32397@darcs.net> On Wed, Jun 11, 2008 at 06:41:37AM -0700, Jonathan Cast wrote: > On Wed, 2008-06-11 at 11:08 +0100, Duncan Coutts wrote: > > All these things are already possible (if not easy) using custom code in > > the Setup.hs script and/or using a ./configure script. > > I assume the claim above about cabal-install failing to install such a > package is incorrect, right? > > Beyond which, to paraphrase what I tell my boss at work, I can get > Setup.lhs to do anything I want, it's written in a Turing-complete > language. But I'd rather not use a tool I'm going to have to fight. Indeed, that's the advantage of using systems like autoconf and make: they're written with extensibility in mind. David From judah.jacobson at gmail.com Wed Jun 11 14:26:14 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Wed Jun 11 14:18:43 2008 Subject: darcs patch: Re: Readline readHistory & writeHistory API broken Message-ID: <6d74b0d20806111126t5ab5c3afn7691a4d824b29a97@mail.gmail.com> On Wed, Jun 11, 2008 at 5:04 AM, Krasimir Angelov wrote: > 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. >> I agree that just fixing the comments is fine. Ian, it looks like the editline library also has this problem. Can you please apply the attached patch (or its equivalent)? Wed Jun 11 11:16:24 PDT 2008 Judah Jacobson * Remove erroneous comment from readHistory and writeHistory. M ./System/Console/Editline/Readline.hsc -2 +2 Thanks, -Judah -------------- next part -------------- A non-text attachment was scrubbed... Name: nonnull.patch Type: application/octet-stream Size: 1734 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20080611/b1ccdfa6/nonnull.obj From david.waern at gmail.com Wed Jun 11 16:35:52 2008 From: david.waern at gmail.com (David Waern) Date: Wed Jun 11 16:28:05 2008 Subject: haddock: record types with partially exported fields In-Reply-To: <20080611140533.GA9133@matrix.chaos.earth.li> References: <483D7D53.4080105@hot.ee> <20080605161739.GA4187@soi.city.ac.uk> <20080611110720.GA15187@matrix.chaos.earth.li> <20080611135753.GA10342@soi.city.ac.uk> <20080611140533.GA9133@matrix.chaos.earth.li> Message-ID: 2008/6/11 Ian Lynagh : > On Wed, Jun 11, 2008 at 02:57:53PM +0100, Ross Paterson wrote: >> On Wed, Jun 11, 2008 at 01:29:20PM +0200, 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? > > I'd prefer it to be separate, on balance. Separate it is. http://trac.haskell.org/haddock/ No content yet. David From duncan.coutts at worc.ox.ac.uk Wed Jun 11 18:52:37 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jun 11 18:40:44 2008 Subject: installing non-haskell binaries with cabal In-Reply-To: <1213191697.6318.4.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> <1213178931.15010.481.camel@localhost> <1213191697.6318.4.camel@jonathans-macbook> Message-ID: <1213224757.15010.494.camel@localhost> On Wed, 2008-06-11 at 06:41 -0700, Jonathan Cast wrote: > > > 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. > > I assume the claim above about cabal-install failing to install such a > package is incorrect, right? Right. cabal-install works perfectly well with packages that use custom Setup.hs scripts. It picks a suitable version of the Cabal library to build them with. > Beyond which, to paraphrase what I tell my boss at work, I can get > Setup.lhs to do anything I want, it's written in a Turing-complete > language. But I'd rather not use a tool I'm going to have to fight. The honest situation is this: the Setup.hs can override hooks into pretty much every phase of configuration, build and installation (see UserHooks module) and you can use any of the base and other core libs to do what you want. So yes, you can do pretty much anything, however the API to get information out of Cabal and to use its functions is of variable utility and stability because the API that setup.hs scripts are expected to use has never been carefully delineated or designed. We now know a lot more about how it *should* be designed but that's not of any immediate help to you. So as people say, once you start to need a custom Setup.hs things become rather harder. On the other hand it is still probably a good deal easier than writing a custom build system with make + autoconf and making that easy to deploy. If you find specific tasks you'd like to be able to do but are currently tricky then file feature requests. Duncan From avatar at hot.ee Thu Jun 12 09:48:26 2008 From: avatar at hot.ee (Misha Aizatulin) Date: Thu Jun 12 09:40:46 2008 Subject: installing non-haskell binaries with cabal In-Reply-To: <1213224757.15010.494.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> <1213191697.6318.4.camel@jonathans-macbook> <1213224757.15010.494.camel@localhost> Message-ID: <4851292A.7070901@hot.ee> Duncan Coutts wrote: > If you find specific tasks you'd like to be able to do but are currently > tricky then file feature requests. that was just my plan, here is the ticket: http://hackage.haskell.org/trac/hackage/ticket/293 Misha From igloo at earth.li Thu Jun 12 10:32:38 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu Jun 12 10:24:49 2008 Subject: darcs patch: Re: Readline readHistory & writeHistory API broken In-Reply-To: <6d74b0d20806111126t5ab5c3afn7691a4d824b29a97@mail.gmail.com> References: <6d74b0d20806111126t5ab5c3afn7691a4d824b29a97@mail.gmail.com> Message-ID: <20080612143238.GA12417@matrix.chaos.earth.li> On Wed, Jun 11, 2008 at 11:26:14AM -0700, Judah Jacobson wrote: > > I agree that just fixing the comments is fine. > > Ian, it looks like the editline library also has this problem. Can > you please apply the attached patch (or its equivalent)? Thanks; it's in my repo now, so will be pushed next time I validate. Presumably you plan to also push it to the repo at http://code.haskell.org/editline ? I'd like to keep the GHC rep a subset of that one so that we don't have unnecessary conflicts etc. Thanks Ian From judah.jacobson at gmail.com Thu Jun 12 13:24:13 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Thu Jun 12 13:16:29 2008 Subject: darcs patch: Re: Readline readHistory & writeHistory API broken In-Reply-To: <20080612143238.GA12417@matrix.chaos.earth.li> References: <6d74b0d20806111126t5ab5c3afn7691a4d824b29a97@mail.gmail.com> <20080612143238.GA12417@matrix.chaos.earth.li> Message-ID: <6d74b0d20806121024u70fe3343oaecb843f42c9a585@mail.gmail.com> On Thu, Jun 12, 2008 at 7:32 AM, Ian Lynagh wrote: > On Wed, Jun 11, 2008 at 11:26:14AM -0700, Judah Jacobson wrote: >> >> I agree that just fixing the comments is fine. >> >> Ian, it looks like the editline library also has this problem. Can >> you please apply the attached patch (or its equivalent)? > > Thanks; it's in my repo now, so will be pushed next time I validate. > Presumably you plan to also push it to the repo at > http://code.haskell.org/editline > ? I'd like to keep the GHC rep a subset of that one so that we don't > have unnecessary conflicts etc. Sure; I was waiting for you to push to the GHC repo first, but your plan sounds fine. I've pushed the patch to code.haskell.org. -Judah From isaacdupree at charter.net Fri Jun 13 08:59:34 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Fri Jun 13 08:51:46 2008 Subject: Maybe-summary was: Re: [Haskell-cafe] Re: [Haskell] ANN: random-access-list-0.1 In-Reply-To: <005201c8cd51$0d775ab0$213c7ad5@cr3lt> References: <48505344.4010809@web.de> <48507431.2080908@charter.net><48516EEA.6020203@web.de> <485256C6.2010204@charter.net> <005201c8cd51$0d775ab0$213c7ad5@cr3lt> Message-ID: <48526F36.3020202@charter.net> Claus Reinke wrote: >> To summarize: Monad isn't the proper abstraction for failable/Maybe. >> Maybe is an algebraic data type that *exactly* represents the spirit >> of what you're trying to do: e.g. Conor McBride said: "Maybe is the >> most general abstraction. Requiring (>>=), or even (<*>) seems >> excessive. What we need is "any f with zero and return", so why not >> pick the canonical, initial, inductively defined such thing?" In this >> case the typeclass adds no generality to the function's behaviour >> (Maybe can be trivially converted to any other type, with a combinator >> even). And the confusion that results, when the function is almost >> always used at type Maybe anyway. If you want to read the whole >> discussion... if you haven't been subscribed to libraries@haskell.org >> , it's archived: >> http://thread.gmane.org/gmane.comp.lang.haskell.libraries/9082 > > Thanks for the summary. I had been wondering about this > change of mood, and I disagree with the suggestion that > Maybe Nothing is the right replacement for Monad fail. > Whether fail should be in Monad, or whether we really want MonadZero, > MonadPlus, MonadError, or something else entirely has been open for > discussion, but it is easily shown > that Maybe is not the most general abstraction - it loses information > wrt to (Either String), for instance: > > Prelude> let {f [] = fail "empty"; f [_] = fail "singleton"; f l = > return l } okay, I see, it's just that most partial functions in Data.* / container libraries don't really have multiple failure modes that need distinguishing. You could say, in a type/information-theoretic mindset, that even your "f [_]" above loses information because it doesn't vary based on the _ (and so it isn't reversible) (and this is very common and normal especially for error messages, but there's a large design space for places where they're needed, depending on whether a machine needs to understand the message, etc.) I think we didn't conclude much about e.g. parser-library return types, because we (thankfully) weren't trying to. -Isaac From claus.reinke at talk21.com Fri Jun 13 10:43:19 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Jun 13 10:35:40 2008 Subject: Maybe-summary was: Re: [Haskell-cafe] Re: [Haskell] ANN:random-access-list-0.1 References: <48505344.4010809@web.de><48507431.2080908@charter.net><48516EEA.6020203@web.de><485256C6.2010204@charter.net><005201c8cd51$0d775ab0$213c7ad5@cr3lt> <48526F36.3020202@charter.net> Message-ID: <006e01c8cd63$d48d8540$213c7ad5@cr3lt> >>> http://thread.gmane.org/gmane.comp.lang.haskell.libraries/9082 .. >> that Maybe is not the most general abstraction - it loses information >> wrt to (Either String), for instance: >> >> Prelude> let {f [] = fail "empty"; f [_] = fail "singleton"; f l = >> return l } > > okay, I see, it's just that most partial functions in Data.* / container > libraries don't really have multiple failure modes that need > distinguishing. Yes, I noticed that Ross was careful to note that in the message that started that thread. I was more concerned with that specific case being generalized to an argument against not-just-Maybe (I think that was the title on the old wiki?). And single failure mode in the components doesn't imply single failure mode in combinations, either. Consider import Control.Monad import Control.Monad.Error f 1 = return 1 f _ = fail "f" g 2 = return 2 g _ = fail "g" If I call 'f', and it fails, I know that it was 'f' that failed, and it could only fail in a single way, so there's really no point in not replacing 'fail "f"' with 'Nothing', right (and the same goes for 'g')? Wrong (or Left;-)! Combining functions with single failure modes gives combinations with multiple failure modes (think of different branches in a parser/ type system/.., or of different phases in a compiler). Compare the two outputs of 'test' below: forg n = f n `mplus` g n gorf n = g n `mplus` f n fandg n = f n >>= g gandf n = g n >>= f test = do print ([forg 3, gorf 3, fandg 1, fandg 2]::[Maybe Int]) print ([forg 3, gorf 3, fandg 1, fandg 2]::[Either String Int]) I don't know whether that is an immediate concern for the particular functions under discussion from the 'containers' package, apart from all the extra lifting (and re-adding of sensible failure messages) when wanting to use those functions in a non-Maybe Monad? But it is a concern in general monadic programming (and it often requires extra work to ensure that failure paths combine as well as success paths). Claus PS: There was also the argument that there are cases where local failure handling is just not sensible (what the Erlangers call "don't program defensively", or "let it crash"), and where trying to return and handle those 'Nothing's would only make the code less readable as the problem gets passed from Pontius to Pilatus. The "let someone else clean up" approach is also supported by the not-just-Maybe pattern, although not as well in Haskell as in Erlang (with its supervisor trees and heart-beat monitoring). From waldmann at imn.htwk-leipzig.de Mon Jun 16 02:47:35 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Mon Jun 16 02:39:33 2008 Subject: HTTP(S) ? Message-ID: <48560C87.5090500@imn.htwk-leipzig.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 can the HTTP module handle https connections? would this then work with haxr: remote "https://foo.bar/cgi-bin/server.cgi" ... best regards, J.W. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIVgyHDqiTJ5Q4dm8RAv6NAKChUNuQWdW1Ej8YY3+/GeqR+b3TiACcCxha hIFujlBcmWGxiplXo519USo= =gO8x -----END PGP SIGNATURE----- From dons at galois.com Mon Jun 16 03:04:54 2008 From: dons at galois.com (Don Stewart) Date: Mon Jun 16 02:56:56 2008 Subject: HTTP(S) ? In-Reply-To: <48560C87.5090500@imn.htwk-leipzig.de> References: <48560C87.5090500@imn.htwk-leipzig.de> Message-ID: <20080616070454.GA4011@scytale.galois.com> If not, the curl library can. -- Don waldmann: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > can the HTTP module handle https connections? > > would this then work with haxr: > remote "https://foo.bar/cgi-bin/server.cgi" ... > > best regards, J.W. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.4-svn0 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFIVgyHDqiTJ5Q4dm8RAv6NAKChUNuQWdW1Ej8YY3+/GeqR+b3TiACcCxha > hIFujlBcmWGxiplXo519USo= > =gO8x > -----END PGP SIGNATURE----- > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From alistair at abayley.org Mon Jun 16 09:15:37 2008 From: alistair at abayley.org (Alistair Bayley) Date: Mon Jun 16 09:07:33 2008 Subject: Cabal-1.4: library-dirs and include-dirs missing from package description after install Message-ID: <79d7c4980806160615rdf5c0f6wa6a189128b3bf5ff@mail.gmail.com> I'm trying to build and install Takusen 0.8.2 with a new .cabal and Setup, using Cabal-1.4.0.0. The Setup program writes out an updated Takusen.buildinfo (below) from the postConf hook. However, the library-dirs and include-dirs fields are not included in the package description when installed. Any ideas as to what I'm doing wrong? Alistair --------------- Takusen.buildinfo --------------------- buildable: True build-tools: odbcconf -any, sqlplus -any, pg_config -any, sqlite3 -any cpp-options: cc-options: ld-options: --enable-stdcall-fixup pkgconfig-depends: frameworks: c-sources: extensions: CPP extra-libraries: odbc32 oci pq sqlite3 extra-lib-dirs: "C:\\Program Files\\sqlite3\\" C:/PROGRA~1/POSTGR~1/8.1/lib C:\oracle\product\10.2.0\client_1\bin includes: install-includes: include-dirs: "C:\\Program Files\\sqlite3\\" C:/PROGRA~1/POSTGR~1/8.1/include C:/PROGRA~1/POSTGR~1/8.1/include/server C:\oracle\product\10.2.0\client_1\oci\include hs-source-dirs: . other-modules: Database.InternalEnumerator ghc-prof-options: -prof -auto-all ghc-shared-options: -prof -auto-all ghc-options: hugs-options: nhc98-options: jhc-options: ------------------------------------------------------------------------ ghc-pkg describe Takusen-0.8.2: name: Takusen version: 0.8.2 license: BSD3 copyright: 2003-2008, Alistair Bayley, Oleg Kiselyov maintainer: alistair@abayley.org, oleg@pobox.com stability: experimental homepage: http://darcs.haskell.org/takusen package-url: http://darcs.haskell.org/takusen description: Takusen is a DBMS access library. ... category: Database author: Alistair Bayley, Oleg Kiselyov exposed: True exposed-modules: Database.ODBC.Enumerator Database.ODBC.OdbcFunctions Database.Oracle.Enumerator Database.Oracle.OCIConstants Database.Oracle.OCIFunctions Database.PostgreSQL.Enumerator Database.PostgreSQL.PGFunctions Database.Sqlite.Enumerator Database.Sqlite.SqliteFunctions Database.Enumerator Database.Util Database.Stub.Enumerator Control.Exception.MonadIO Foreign.C.UTF8 hidden-modules: Database.InternalEnumerator import-dirs: "C:\\Program Files\\Haskell\\Takusen-0.8.2\\ghc-6.8.1" library-dirs: "C:\\Program Files\\Haskell\\Takusen-0.8.2\\ghc-6.8.1" hs-libraries: HSTakusen-0.8.2 extra-libraries: odbc32 oci pq sqlite3 extra-ghci-libraries: include-dirs: includes: depends: base-3.0.0.0 mtl-1.1.0.0 old-time-1.0.0.0 time-1.1.2.0 hugs-options: cc-options: ld-options: --enable-stdcall-fixup framework-dirs: frameworks: haddock-interfaces: "C:\\Program Files\\Haskell\\doc\\Takusen-0.8.2\\html\\Takusen.haddock" haddock-html: "C:\\Program Files\\Haskell\\doc\\Takusen-0.8.2\\html" From duncan.coutts at worc.ox.ac.uk Mon Jun 16 14:58:55 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Jun 16 14:49:24 2008 Subject: Cabal-1.4: library-dirs and include-dirs missing from package description after install In-Reply-To: <79d7c4980806160615rdf5c0f6wa6a189128b3bf5ff@mail.gmail.com> References: <79d7c4980806160615rdf5c0f6wa6a189128b3bf5ff@mail.gmail.com> Message-ID: <1213642735.15010.651.camel@localhost> On Mon, 2008-06-16 at 14:15 +0100, Alistair Bayley wrote: > I'm trying to build and install Takusen 0.8.2 with a new .cabal and > Setup, using Cabal-1.4.0.0. The Setup program writes out an updated > Takusen.buildinfo (below) from the postConf hook. However, the > library-dirs and include-dirs fields are not included in the package > description when installed. > > Any ideas as to what I'm doing wrong? I cannot reproduce this problem. It works fine for me. I made a dummy takusen.cabal: name: takusen version: 0 build-type: Configure library -- nothing here and your takusen.buildinfo > --------------- Takusen.buildinfo --------------------- > buildable: True > build-tools: odbcconf -any, sqlplus -any, pg_config -any, > sqlite3 -any > cpp-options: > cc-options: > ld-options: --enable-stdcall-fixup > pkgconfig-depends: > frameworks: > c-sources: > extensions: CPP > extra-libraries: odbc32 oci pq sqlite3 > extra-lib-dirs: "C:\\Program Files\\sqlite3\\" > C:/PROGRA~1/POSTGR~1/8.1/lib > C:\oracle\product\10.2.0\client_1\bin I assume you did actually have the above line properly indented. With it as it is you get a parse error when reading in the buildinfo file. > includes: > install-includes: > include-dirs: "C:\\Program Files\\sqlite3\\" > C:/PROGRA~1/POSTGR~1/8.1/include > C:/PROGRA~1/POSTGR~1/8.1/include/server > C:\oracle\product\10.2.0\client_1\oci\include > hs-source-dirs: . > other-modules: Database.InternalEnumerator > ghc-prof-options: -prof -auto-all > ghc-shared-options: -prof -auto-all > ghc-options: > hugs-options: > nhc98-options: > jhc-options: Then I do $ cabal configure $ cabal register --gen-pkg-config and looking at the takusen-0.conf the library-dirs and include-dirs contain all the dirs given in takusen.buildinfo. This is obviously on Windows. On linux it would not work since C:\etc are not absolute paths on unix but they are on Windows. So I'll need more precise details on how to reproduce the problem. Is there a darcs repo I should use? What commands should I use exactly? Duncan From jcb73 at cam.ac.uk Mon Jun 16 15:28:32 2008 From: jcb73 at cam.ac.uk (Jamie Brandon) Date: Mon Jun 16 15:20:29 2008 Subject: Generic tries (long) Message-ID: <10ed1a750806161228t12b974dx18395853e2b9e5f2@mail.gmail.com> Hi, I'm writing a library for generic tries for the Summer of Code. The main point of this post is to get some feedback on the api but I'll briefly explain the idea. The point of a trie is to exploit the recursive nature of ADTs to save on expensive key comparisons and reduce space consumption. Hinze' original formulation is very elegant but results in very deep structures and is fairly inefficient. The normal trie optimisations (concatenating singleton maps, mainly) cant be applied to the generic version. I intend instead to encode ADTs as lists. This encoding can range from a simple walk of the ADT to creating a compressed, bit packing representation. The resulting tradeoff between encoding time and space usage should make the design fairly flexible. This will look something like: class Serial k where -- | Flattened form of key consists of a list of Nodes -- Node will be Int or UArray Int for compressed implementations type Node k -- | Flatten to a list of Nodes serialise :: k -> [Node k] -- | Reconstruct from a list of Nodes unserialise :: [Node k] -> k The api below is mostly cribbed from Adrian Hey's initial design. Guarantees about ordering will probably vary between maps. All ascending have descending version too. Strict versions of functions will be written where appropriate, I've omitted them here for brevity. Key reconstruction is likely to be expensive so it may make more sense to seperate foldrKeys and friends into a seperate class. Adrian has written instance of GMap for lists, UInts and Ord types so I can declare instance (Serial k) => GMap (ListGMap (Node k)) k where ... etc I should have a spot on code.haskell.org soon, at which point I'll put up a Haddock page with the most up to date version of the api. class GMap map where type k -- | The empty map. empty :: map a -- | Create a map with a single association. singleton :: k -> a -> map a -- | Create a map from a list of associations which /must/ be in ascending order of keys -- (with /no/ duplicate keys). If in doubt use one of the safer (but slower) 'fromAssocs' functions. fromAssocsAscending :: [(k,a)] -> map a -- | Return 'True' if the map contains no associations. isEmpty :: map a -> Bool -- | Return 'True' if the map contains exactly one association. isSingleton :: map a -> Bool -- | Return the value associated with the supplied key (if any). lookup :: k -> map a -> Maybe a -- | Insert a new association in the map if there is currently no value associated with the key. -- If there is a value associated with the key then replace it with the result of -- applying the supplied function to that value. insert :: (a -> a) -> k -> a -> map a -> map a -- | Delete the association for the supplied key (if any). delete :: k -> map a -> map a -- | This is a combined insert\/modify\/delete operation. The argument to the supplied function -- is ('Just' a) if there is a value (a) associated with the supplied key, otherwise 'Nothing'. -- If the return value is ('Just' a'), a' becomes the new value associated with the supplied key. -- If the return value is 'Nothing', the association for the supplied key (if any) is deleted. alter :: (Maybe a -> Maybe a) -> k -> map a -> map a -- | Evaluate the union of two maps. If the maps contain common keys then combine the -- values associated with those keys using the supplied function. The value arguments -- to this function are supplied in the same order as the map arguments. union :: (a -> a -> a) -> map a -> map a -> map a -- | Evaluate the intersection of two maps, combining common associations using the supplied function. intersection :: (a -> b -> c) -> map a -> map b -> map c -- | Evaluate the difference between two maps. For any key occuring in the second map, -- the corresponding association (if any) is deleted from the first map. -- The associated values in the second map are irrelevant. difference :: map a -> map b -> map a -- | Returns true if the keys in the first map are a subset of the keys in the second map. -- (This includes the case where the key sets are identical). Note that this function does -- not examine the associated values (which are irrelevant). See 'isSubmapOf' if you -- do want associated values examined. isSubsetOf :: map a -> map b -> Bool -- | Returns true if the keys in the first map are a subset of the keys in the second map -- and the corresponding function always returns true when applied to the values associated -- with matching keys. isSubmapOf :: (a -> b -> Bool) -> map a -> map b -> Bool -- | Apply the supplied function to every associated value in the map. map :: (a -> b) -> map a -> map b -- | Apply the supplied function to every association in the map, and use the result -- as the new associated value for the corresponding key. mapWithKey :: (k -> a -> b) -> map a -> map b -- | Delete associations for which the supplied predicate returns 'False' when applied to -- the associated value. filter :: (a -> Bool) -> map a -> map a -- | Fold right over the list of elements in ascending order of keys. -- See 'foldrElemsAscending'' for a strict version of this function. foldrElemsAscending :: (a -> b -> b) -> map a -> b -> b -- | Fold right over the list of keys in ascending order. -- See 'foldrKeysAscending'' for a strict version of this function. foldrKeysAscending :: (k -> b -> b) -> map a -> b -> b -- | Fold right over the list of associations in ascending order of keys. -- See 'foldrAssocsAscending'' for a strict version of this function. foldrAssocsAscending :: (k -> a -> b -> b) -> map a -> b -> b -- | Fold over elements in un-specified order using /unboxed/ Int accumulator (with GHC). -- Defaults to boxed Int for other Haskells. Typically used for counting functions. -- Implementations are free to traverse the map in any order. -- The folded function is always applied strictly. foldElemsUINT :: (a -> UINT -> UINT) -> map a -> UINT -> UINT In addition there a few functions which are useful for groups of maps or nested maps. -- | Add the number of associations in a map to the supplied /unboxed/ Int (with GHC). -- Defaults to boxed Int for other Haskells. addSize :: map a -> UINT -> UINT -- | Find the value associated with the supplied key (if any) and return the result -- of applying the supplied continuation function to that value. Useful for nested lookup. lookupCont :: (a -> Maybe b) -> k -> map a -> Maybe b -- | Reject empty maps (return Nothing). nonEmpty :: map a -> Maybe (map a) The following functions are useful internally as most of the maps are defined in terms of simpler maps. Also see this thread on the need for unionMaybe. -- | Similar to 'insert', but the association is deleted if the supplied function returns 'Nothing'. -- (The supplied function is always applied strictly.) insertMaybe :: (a -> Maybe a) -> k -> a -> map a -> map a -- | Find the value associated with the supplied key (if any) and apply the supplied function -- to that value. Delete the association if the result is 'Nothing'. Replace the old value with -- the new value if the result is ('Just' something). -- (The supplied function is always applied strictly.) deleteMaybe :: (a -> Maybe a) -> k -> map a -> map a -- | Evaluate the union of two maps, but delete combined associations from the result map -- if the combining function returns 'Nothing'. -- (The combining function is always applied strictly.) unionMaybe :: (a -> a -> Maybe a) -> map a -> map a -> map a -- | Evaluate the intersection of two maps, but delete combined associations from the result map -- if the combining function returns 'Nothing'. -- (The combining function is always applied strictly.) intersectionMaybe :: (a -> b -> Maybe c) -> map a -> map b -> map c -- | Difference with a combining function. If the combining function returns -- @Just a@ then the corresponding association is not deleted from the result map -- (it is retained with @a@ as the associated value). differenceMaybe :: (a -> b -> Maybe a) -> map a -> map b -> map a -- | Apply the supplied function to every associated value in the map. -- If the result is 'Nothing' then the delete the corresponding association. -- (The supplied function is always applied strictly.) mapMaybe :: (a -> Maybe b) -> map a -> map b Thanks Jamie From dons at galois.com Mon Jun 16 20:12:54 2008 From: dons at galois.com (Don Stewart) Date: Mon Jun 16 20:04:53 2008 Subject: haxml Message-ID: <20080617001254.GD9848@scytale.galois.com> The haxml version of hackage.haskell.org relied on the deprecated function 'ByteString.join' which has been replaced with 'ByteString.intercalate' since the last release. This means haxml doesn't build with bytestring 0.9.1.0, which some people might have updated to. Malcolm, what should we do ? I can reintroduce 'join' and leave it deprecated for another year, or is there a new haxml release on the horizon? A non-working haxml affects an awful lot of hackage. -- Don From lemming at henning-thielemann.de Tue Jun 17 02:01:42 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Jun 17 01:53:43 2008 Subject: [Haskell-cafe] 1/0 In-Reply-To: <200806161945.30976.dan.doel@gmail.com> References: <2518b95d0806161607p207c20b1rcf083488d246efc5@mail.gmail.com> <200806161945.30976.dan.doel@gmail.com> Message-ID: On Mon, 16 Jun 2008, Dan Doel wrote: > On Monday 16 June 2008, Evan Laforge wrote: > >> (huge negative number) >> >> Ok, so integral types don't have that exceptional value. Shouldn't >> trying to convert NaN or Infinity to an Integral throw something? Is >> it a performance thing? I'd think if you're converting to Integer you >> don't really need hardware level performance anyway, so a couple of >> checks wouldn't kill anyone. > > This is a (known by some) bug of sorts in the various floating point -> > integral transformations (which ultimately boil down to decodeFloat or > something like that at some point). It apparently doesn't know about the > various exceptional values in the IEEE representation, so it just treats the > representation like any other value. Infinity and NaN look like various huge > numbers if you interpret them like any other value, so that's what you get > out of round/ceiling/floor/etc. > > It's not ideal, but I guess no one's bothered to fix it. Might be something to > bring up on the libraries mailing list. This could be combined with improving performance: http://hackage.haskell.org/trac/ghc/ticket/2281 http://hackage.haskell.org/trac/ghc/ticket/2271 http://hackage.haskell.org/trac/ghc/ticket/1434 From ahey at iee.org Tue Jun 17 04:35:10 2008 From: ahey at iee.org (Adrian Hey) Date: Tue Jun 17 04:27:11 2008 Subject: Generic tries (long) In-Reply-To: <10ed1a750806161228t12b974dx18395853e2b9e5f2@mail.gmail.com> References: <10ed1a750806161228t12b974dx18395853e2b9e5f2@mail.gmail.com> Message-ID: <4857773E.9050401@iee.org> Hello All, Folks, could you please check this out and comment on the proposed class API(s), in particular if there's anything that's really bugged you about Data.Map/Set etc now is your chance to get a (hopefully) decent performing lib with your personal wishlist items included. Jamie, I'm sure it would help a lot if you could produce (and update if necessary) documented API proposal using Haddock. The email is rather difficult to follow IMHO (at least with my email client) > Guarantees about ordering will probably vary between maps. I take it you mean different concrete implementations. For classes I think it's important to be clear exactly what is being promised wrt ordering, and that promise must be kept by *all* instances. A "class law" that applies to some instances and not others is no use at all really (we'll end up with kind of mess and confusion we seem to have for the Ord/Eq classes at present :-) As having an explicit Ord constraint is objectionable to some folk and there might indeed be efficient implementations that don't offer any ordering guarantees, it may be good to break that API into an unordered Map class and have a separate subclass for methods that are supposed to deliver on ordering promises. Regarding ordering promises, what do folk think they should be? I think ideally we would want the same Ordering as the corresponding Ord instance (if it exists), but this is hard to guarantee as typically we won't have any control over the Ord instance definition (and won't be using the compare method). Would it be OK to simply to promise that the Ordering is the same as that that would be wholly derived? In which case we wouldn't want the Ord constraint, but we probably would want our own private compare method (which generally won't agree with Ords compare). If we want ordering that's guaranteed to be consistent with Ord (and have a meaningful Ord constraint), I can think of two ways to do this: 1- Have users write the matching instance by hand (a huge amount of work if we're talking about a generalised trie). 2- Fall back on balanced tree implementation and actually use Ords compare method (slow). Regards -- Adrian Hey From Malcolm.Wallace at cs.york.ac.uk Tue Jun 17 05:44:10 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Jun 17 05:37:03 2008 Subject: haxml In-Reply-To: <20080617001254.GD9848@scytale.galois.com> References: <20080617001254.GD9848@scytale.galois.com> Message-ID: <20080617104410.62a8742b.Malcolm.Wallace@cs.york.ac.uk> Don Stewart wrote: > This means haxml doesn't build with bytestring 0.9.1.0, which some > people might have updated to. I have updated the HaXml package on Hackage to 1.19.3, changing the dependency on 'join' to 'intercalate'. Thanks for the prompt to fix this. Regards, Malcolm From alistair at abayley.org Tue Jun 17 06:50:10 2008 From: alistair at abayley.org (Alistair Bayley) Date: Tue Jun 17 06:42:05 2008 Subject: Cabal-1.4: library-dirs and include-dirs missing from package description after install In-Reply-To: <1213642735.15010.651.camel@localhost> References: <79d7c4980806160615rdf5c0f6wa6a189128b3bf5ff@mail.gmail.com> <1213642735.15010.651.camel@localhost> Message-ID: <79d7c4980806170350w17857325ve090338df482f5d5@mail.gmail.com> > I cannot reproduce this problem. It works fine for me. > > I made a dummy takusen.cabal: > and your takusen.buildinfo > I assume you did actually have the above line properly indented. With it > as it is you get a parse error when reading in the buildinfo file. Yes, cut'n'paste error. > So I'll need more precise details on how to reproduce the problem. Is > there a darcs repo I should use? What commands should I use exactly? I've pushed the current Setup and .cabal to our repo. You can say: darcs get http://darcs.haskell.org/takusen Then do this: ghc --make Setup setup configure -fodbc -fsqlite -fpostgres (note that you need to have these backends on your path; perhaps just -fodbc -fsqlite for you?) setup register --gen-pkg-config I've just done this. Takusen.buildinfo contains: extra-libraries: odbc32 pq sqlite3 extra-lib-dirs: "C:\\Program Files\\sqlite3\\" C:/PROGRA~1/POSTGR~1/8.1/lib includes: install-includes: include-dirs: "C:\\Program Files\\sqlite3\\" C:/PROGRA~1/POSTGR~1/8.1/include C:/PROGRA~1/POSTGR~1/8.1/include/server but Takusen-0.8.2.conf has: import-dirs: "C:\\Program Files\\Haskell\\Takusen-0.8.2\\ghc-6.8.1" library-dirs: "C:\\Program Files\\Haskell\\Takusen-0.8.2\\ghc-6.8.1" hs-libraries: HSTakusen-0.8.2 extra-libraries: odbc32 pq sqlite3 extra-ghci-libraries: include-dirs: includes: Alistair From kolmodin at dtek.chalmers.se Tue Jun 17 11:09:50 2008 From: kolmodin at dtek.chalmers.se (Lennart Kolmodin) Date: Tue Jun 17 10:56:01 2008 Subject: haxml In-Reply-To: <20080617001254.GD9848@scytale.galois.com> References: <20080617001254.GD9848@scytale.galois.com> Message-ID: <4857D3BE.6020508@dtek.chalmers.se> Don Stewart wrote: > The haxml version of hackage.haskell.org relied on the deprecated > function 'ByteString.join' which has been replaced with > 'ByteString.intercalate' since the last release. > > This means haxml doesn't build with bytestring 0.9.1.0, which some > people might have updated to. In Gentoo we apply this patch before compiling: http://haskell.org/~gentoo/gentoo-haskell/dev-haskell/haxml/files/haxml-1.19.2-intercalate.patch as join and intercalcate seems to be the same functions with different names. The interesting part is the comment in the header of the patch... > Malcolm, what should we do ? I can reintroduce 'join' and leave it > deprecated for another year, or is there a new haxml release on the > horizon? -- kolmodin From dons at galois.com Tue Jun 17 11:35:06 2008 From: dons at galois.com (Don Stewart) Date: Tue Jun 17 11:27:19 2008 Subject: haxml In-Reply-To: <20080617104410.62a8742b.Malcolm.Wallace@cs.york.ac.uk> References: <20080617001254.GD9848@scytale.galois.com> <20080617104410.62a8742b.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <20080617153506.GA18127@scytale.galois.com> Malcolm.Wallace: > Don Stewart wrote: > > > This means haxml doesn't build with bytestring 0.9.1.0, which some > > people might have updated to. > > I have updated the HaXml package on Hackage to 1.19.3, changing the > dependency on 'join' to 'intercalate'. Thanks for the prompt to fix this. Hmm, when I try to build this via cabal install, it fails at: src/tools/Xtract.hs:19:7: Could not find module `Text.XML.HaXml.Util': Use -v to see a list of the files searched for. hackage also failed at this point. Any ideas? -- Don From Malcolm.Wallace at cs.york.ac.uk Tue Jun 17 11:56:38 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Jun 17 11:52:14 2008 Subject: haxml In-Reply-To: <20080617153506.GA18127@scytale.galois.com> References: <20080617001254.GD9848@scytale.galois.com> <20080617104410.62a8742b.Malcolm.Wallace@cs.york.ac.uk> <20080617153506.GA18127@scytale.galois.com> Message-ID: <20080617165638.7cd90c97.Malcolm.Wallace@cs.york.ac.uk> Don Stewart wrote: > > I have updated the HaXml package on Hackage to 1.19.3 > > src/tools/Xtract.hs:19:7: > Could not find module `Text.XML.HaXml.Util': Oops. The perils of accepting patches from third parties, without subsequently checking all possible ways of building and installing. Yet another new version (1.19.4) uploaded to fix this. Regards, Malcolm From dons at galois.com Tue Jun 17 13:49:58 2008 From: dons at galois.com (Don Stewart) Date: Tue Jun 17 13:42:14 2008 Subject: haxml In-Reply-To: <20080617165638.7cd90c97.Malcolm.Wallace@cs.york.ac.uk> References: <20080617001254.GD9848@scytale.galois.com> <20080617104410.62a8742b.Malcolm.Wallace@cs.york.ac.uk> <20080617153506.GA18127@scytale.galois.com> <20080617165638.7cd90c97.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <20080617174958.GA19304@scytale.galois.com> Malcolm.Wallace: > Don Stewart wrote: > > > > I have updated the HaXml package on Hackage to 1.19.3 > > > > src/tools/Xtract.hs:19:7: > > Could not find module `Text.XML.HaXml.Util': > > Oops. The perils of accepting patches from third parties, without > subsequently checking all possible ways of building and installing. > > Yet another new version (1.19.4) uploaded to fix this. Great, thanks Malcolm! It's in Arch Linux now, http://aur.archlinux.org/packages.php?ID=17803 And this all the things that use HaXml will likely build automatically now. -- Don From dons at galois.com Tue Jun 17 19:26:06 2008 From: dons at galois.com (Don Stewart) Date: Tue Jun 17 19:18:01 2008 Subject: Broken packages on hackage Message-ID: <20080617232606.GN19304@scytale.galois.com> Just did a full run over hackage, building packages with ghc 6.8.2, bytestring 0.9.0.1 and cabal 1.4.1.. Several hundred packages built fine. The majority are relatively easy to fix, if the upstream authors can be contacted. The following could be marked broken, if we could do that. Easy: Doesn't support small-base: AGI libxml newbinary openafp StategyLib Catch classify collections compression dataenc derangement hogg hsc2hs 2006 hslogger hsns hsql lambdaFeed metaplug mime-string pointfree sat soegtk sparsecheck special-functors (needs base<2 !) suffixtree th-lift torrent udcode More work: Broken: BerkleyDB -- missing extra-libs at least dbus -- various things. encode -- type errors flippi -- depends on unreleased cgi version finance-treasury -- needs new hxt-filter (author has patch) HsPerl5-0.0.4 -- cc1: error: unrecognized command line option "-Wl" HsSVN -- missing extra-libraries: svn Monadius -- missing: extra-libraries: glut shu-thing -- missing: extra-libraries: glut postgresql -- Too many parameters for class `MonadDatabase' probabilitymonads -- Illegal instance declaration sdl -- gcc: unrecognized option '-rpath' baskell -- missing modules bot -- Duplciate Instance cabal-setup -- type error cabal-tests -- Could not find module `Tests' cabalrpmdeps -- cabal type error clustertools -- missing constructors debian -- cabal type error dephhd -- type error hs-pgms -- missing modules network-rpca -- type error parsely -- missing -XFunctionalDependencies ports -- cpp errro postmaster -- (.text+0x1442): undefined reference to `EVP_mdc2' ? reify -- linker error reifyC roguestar -- Could not find module `Keymaps.CommonKeymap' slackbuild -- cabal innards lax -- cabal innards lhs2tex -- cabal innards rss -- needs haxml 1.3..<1.4 scenegraph -- source for Graphics.SceneGraph.SimpleViewport shell-pipe -- `GHC.Handle' does not export `openFd' srcinst -- module Dpkg missing state -- Setup: COPYRIGHT: copyFile: does not exist storablevector -- QC arbitrary missing Control.Monad.Instances truelevel -- Could not find module `TrueLevelArgs' type-int -- Could not find module `Data.Type.Sign' GHC error: WURFL --stack overflow on large file cedict -- stack oflow on 32k large list cpuid -- Error: suffix or operands invalid for `test' Depends on something hidden: HDBC-postgresql-1.1.4.0, Cabal version: >=1.2 && <1.3 Takusen cabal-upload regex-dfa regex-parsec regex-pcre regex-tdfa -- Don From dons at galois.com Wed Jun 18 02:03:09 2008 From: dons at galois.com (Don Stewart) Date: Wed Jun 18 01:55:07 2008 Subject: Broken packages on hackage In-Reply-To: <20080617232606.GN19304@scytale.galois.com> References: <20080617232606.GN19304@scytale.galois.com> Message-ID: <20080618060309.GE21778@scytale.galois.com> dons: > Just did a full run over hackage, building packages with ghc 6.8.2, > bytestring 0.9.0.1 and cabal 1.4.1.. > > Several hundred packages built fine. > The majority are relatively easy to fix, if the upstream authors > can be contacted. > > The following could be marked broken, if we could do that. > > Easy: > Doesn't support small-base: > AGI > libxml > newbinary > openafp > StategyLib > Catch > classify > collections > compression > dataenc > derangement > hogg > hsc2hs 2006 > hslogger > hsns > hsql > lambdaFeed > metaplug > mime-string > pointfree > sat > soegtk > sparsecheck > special-functors (needs base<2 !) > suffixtree > th-lift > torrent > udcode libxml works now, collections has been updated, and hslogger was in the list by accident. -- Don From haskell at list.mightyreason.com Wed Jun 18 02:42:41 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Wed Jun 18 02:34:39 2008 Subject: Broken packages on hackage In-Reply-To: <20080617232606.GN19304@scytale.galois.com> References: <20080617232606.GN19304@scytale.galois.com> Message-ID: <4858AE61.3030902@list.mightyreason.com> Don Stewart wrote: > Just did a full run over hackage, building packages with ghc 6.8.2, > bytestring 0.9.0.1 and cabal 1.4.1.. > > The following could be marked broken, if we could do that. > > Depends on something hidden: > regex-dfa > regex-parsec > regex-pcre > regex-tdfa At least regex-base and regex-compat build cleanly for you. I had been waiting for the final 6.8.3 to reach macports before recompiling the libraries. And now I see that 6.8.3 final has been announced. I'll upgrade Cabal this week and see if I can get them to compile with 6.8.2 before I upgrade to 6.8.3. Thanks, Chris From jeremy at n-heptane.com Wed Jun 18 03:22:04 2008 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Wed Jun 18 03:11:56 2008 Subject: Broken packages on hackage In-Reply-To: <20080617232606.GN19304@scytale.galois.com> References: <20080617232606.GN19304@scytale.galois.com> Message-ID: <87y753i4wz.wl%jeremy@n-heptane.com> At Tue, 17 Jun 2008 16:26:06 -0700, Don Stewart wrote: > debian -- cabal type error There is a version of this package which works located at: http://src.seereason.com/debian/ It currently depends on a this library: http://src.seereason.com/haskell-extra/ Which includes awesome modules such as, Extra.Misc (I am hoping to add, Extra.Misc.Util someday). I feel a bit weird about uploading a library named 'Extra' to hackage. Especially one that just contains a bunch of random functions that we got tired of copying and pasting into numereous projects. Also, many of the functions in Extra have better implementations in other libraries now, so we would not want new code to be using them. But, I am not sure that I can easily get rid of the dependency on Extra anytime soon, due to lack of time. We could just stake our claim on the Extra namespace -- first come, first serve! Any opinions? j. From sjanssen at cse.unl.edu Wed Jun 18 03:44:04 2008 From: sjanssen at cse.unl.edu (Spencer Janssen) Date: Wed Jun 18 03:36:00 2008 Subject: Broken packages on hackage In-Reply-To: <20080617232606.GN19304@scytale.galois.com> References: <20080617232606.GN19304@scytale.galois.com> Message-ID: <20080618074404.GA7048@celeborn> On Tue, Jun 17, 2008 at 04:26:06PM -0700, Don Stewart wrote: > Just did a full run over hackage, building packages with ghc 6.8.2, > bytestring 0.9.0.1 and cabal 1.4.1.. > > Several hundred packages built fine. > The majority are relatively easy to fix, if the upstream authors > can be contacted. > > The following could be marked broken, if we could do that. I tried building a few of these packages, and my results mostly agree. > dataenc dataenc 0.11 works for me. > hslogger hslogger 1.0.5 works for me (in fact all of the versions on hackage seem to support split base). > special-functors (needs base<2 !) This is explicitly marked as a compatibility package for old GHC versions -- base<2 is intentional. > Monadius -- missing: extra-libraries: glut > shu-thing -- missing: extra-libraries: glut Both of these build and run here. I don't understand why they should have "extra-libraries: glut", don't the extra-libraries belong in the GLUT package instead? > storablevector -- QC arbitrary missing Control.Monad.Instances Builds fine here. However, the tests should not build for a Hackage release, I'll look into this. Cheers, Spencer Janssen From lemming at henning-thielemann.de Wed Jun 18 03:55:32 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Jun 18 03:47:30 2008 Subject: Broken packages on hackage In-Reply-To: <20080617232606.GN19304@scytale.galois.com> References: <20080617232606.GN19304@scytale.galois.com> Message-ID: On Tue, 17 Jun 2008, Don Stewart wrote: > Easy: > Doesn't support small-base: > special-functors (needs base<2 !) of course, because it is a compatibility package ... > More work: > Broken: > shell-pipe -- `GHC.Handle' does not export `openFd' This is also a compatibility package for GHC < 6.4 where no runInteractiveProcess was available. > storablevector -- QC arbitrary missing Control.Monad.Instances I compiled that with GHC-6.8.2 on my machine and it worked and for some reasons it doesn't work on hackage. From duncan.coutts at worc.ox.ac.uk Wed Jun 18 05:27:53 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jun 18 05:15:13 2008 Subject: Broken packages on hackage In-Reply-To: <20080617232606.GN19304@scytale.galois.com> References: <20080617232606.GN19304@scytale.galois.com> Message-ID: <1213781273.15010.792.camel@localhost> On Tue, 2008-06-17 at 16:26 -0700, Don Stewart wrote: > Just did a full run over hackage, building packages with ghc 6.8.2, > bytestring 0.9.0.1 and cabal 1.4.1.. Cheers Don. I'll post my build reports log which covers ~90% of hackage. A couple notes below: > Several hundred packages built fine. > The majority are relatively easy to fix, if the upstream authors > can be contacted. > > The following could be marked broken, if we could do that. > > Easy: > Doesn't support small-base: > AGI > libxml > newbinary > openafp > StategyLib > Catch > classify > collections > compression > dataenc > derangement > hogg > hsc2hs 2006 > hslogger > hsns > hsql > lambdaFeed > metaplug > mime-string > pointfree > sat > soegtk > sparsecheck > special-functors (needs base<2 !) > suffixtree > th-lift > torrent > udcode > > More work: > Broken: > BerkleyDB -- missing extra-libs at least > dbus -- various things. > encode -- type errors > flippi -- depends on unreleased cgi version > finance-treasury -- needs new hxt-filter (author has patch) > HsPerl5-0.0.4 -- cc1: error: unrecognized command line option "-Wl" > HsSVN -- missing extra-libraries: svn > Monadius -- missing: extra-libraries: glut > shu-thing -- missing: extra-libraries: glut > postgresql -- Too many parameters for class `MonadDatabase' > probabilitymonads -- Illegal instance declaration > sdl -- gcc: unrecognized option '-rpath' > baskell -- missing modules > bot -- Duplciate Instance > cabal-setup -- type error Obsoleted by cabal-install > cabal-tests -- Could not find module `Tests' > cabalrpmdeps -- cabal type error > clustertools -- missing constructors > debian -- cabal type error > dephhd -- type error > hs-pgms -- missing modules > network-rpca -- type error > parsely -- missing -XFunctionalDependencies > ports -- cpp errro > postmaster -- (.text+0x1442): undefined reference to `EVP_mdc2' ? > reify -- linker error reifyC > roguestar -- Could not find module `Keymaps.CommonKeymap' > slackbuild -- cabal innards > lax -- cabal innards > lhs2tex -- cabal innards What goes wrong for these ones? lhs2tex works for me with cabal-install and Cabal-1.4. > rss -- needs haxml 1.3..<1.4 > scenegraph -- source for Graphics.SceneGraph.SimpleViewport > shell-pipe -- `GHC.Handle' does not export `openFd' > srcinst -- module Dpkg missing > state -- Setup: COPYRIGHT: copyFile: does not exist > storablevector -- QC arbitrary missing Control.Monad.Instances > truelevel -- Could not find module `TrueLevelArgs' > type-int -- Could not find module `Data.Type.Sign' > > GHC error: > WURFL --stack overflow on large file > cedict -- stack oflow on 32k large list > cpuid -- Error: suffix or operands invalid for `test' > > Depends on something hidden: > HDBC-postgresql-1.1.4.0, Cabal version: >=1.2 && <1.3 > Takusen > cabal-upload Obsoleted by cabal-install > regex-dfa > regex-parsec > regex-pcre > regex-tdfa From magnus at therning.org Wed Jun 18 05:26:17 2008 From: magnus at therning.org (Magnus Therning) Date: Wed Jun 18 05:18:14 2008 Subject: Broken packages on hackage In-Reply-To: <20080617232606.GN19304@scytale.galois.com> References: <20080617232606.GN19304@scytale.galois.com> Message-ID: I see dataenc is in the list below, which I found a bit surprising since it does indeed build fine with the split up base package. However, when I hacked its cabal file I thought it made more sense to use a flag called large_base which defaults to false, rather than a flag called small-base which defaults to true. If the consensus is to use small-base I'll be happy to change it. /M On Wed, Jun 18, 2008 at 12:26 AM, Don Stewart wrote: > Just did a full run over hackage, building packages with ghc 6.8.2, > bytestring 0.9.0.1 and cabal 1.4.1.. > > Several hundred packages built fine. > The majority are relatively easy to fix, if the upstream authors > can be contacted. > > The following could be marked broken, if we could do that. > > Easy: > Doesn't support small-base: > AGI > libxml > newbinary > openafp > StategyLib > Catch > classify > collections > compression > dataenc > derangement > hogg > hsc2hs 2006 > hslogger > hsns > hsql > lambdaFeed > metaplug > mime-string > pointfree > sat > soegtk > sparsecheck > special-functors (needs base<2 !) > suffixtree > th-lift > torrent > udcode > > More work: > Broken: > BerkleyDB -- missing extra-libs at least > dbus -- various things. > encode -- type errors > flippi -- depends on unreleased cgi version > finance-treasury -- needs new hxt-filter (author has patch) > HsPerl5-0.0.4 -- cc1: error: unrecognized command line option > "-Wl" > HsSVN -- missing extra-libraries: svn > Monadius -- missing: extra-libraries: glut > shu-thing -- missing: extra-libraries: glut > postgresql -- Too many parameters for class `MonadDatabase' > probabilitymonads -- Illegal instance declaration > sdl -- gcc: unrecognized option '-rpath' > baskell -- missing modules > bot -- Duplciate Instance > cabal-setup -- type error > cabal-tests -- Could not find module `Tests' > cabalrpmdeps -- cabal type error > clustertools -- missing constructors > debian -- cabal type error > dephhd -- type error > hs-pgms -- missing modules > network-rpca -- type error > parsely -- missing -XFunctionalDependencies > ports -- cpp errro > postmaster -- (.text+0x1442): undefined reference to > `EVP_mdc2' ? > reify -- linker error reifyC > roguestar -- Could not find module `Keymaps.CommonKeymap' > slackbuild -- cabal innards > lax -- cabal innards > lhs2tex -- cabal innards > rss -- needs haxml 1.3..<1.4 > scenegraph -- source for Graphics.SceneGraph.SimpleViewport > shell-pipe -- `GHC.Handle' does not export `openFd' > srcinst -- module Dpkg missing > state -- Setup: COPYRIGHT: copyFile: does not exist > storablevector -- QC arbitrary missing Control.Monad.Instances > truelevel -- Could not find module `TrueLevelArgs' > type-int -- Could not find module `Data.Type.Sign' > > GHC error: > WURFL --stack overflow on large file > cedict -- stack oflow on 32k large list > cpuid -- Error: suffix or operands invalid for `test' > > Depends on something hidden: > HDBC-postgresql-1.1.4.0, Cabal version: >=1.2 && <1.3 > Takusen > cabal-upload > regex-dfa > regex-parsec > regex-pcre > regex-tdfa > > -- Don > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20080618/93746641/attachment.htm From ahey at iee.org Wed Jun 18 07:38:00 2008 From: ahey at iee.org (Adrian Hey) Date: Wed Jun 18 07:30:25 2008 Subject: Package spam :-) Message-ID: <4858F398.20708@iee.org> Hello folks in general and GwernBranwen in particular :-) I don't want to seem ungratful, but I see a lot of the old "new" collections repository has been uploaded to Hackage as separate packages but it really shouldn't be there IMHO. AFAIK most of this stuff has never been properly tested and is in any case not being actively worked on or maintained any more. AvlTree and COrdering have been thoroughly tested and are already in Hackage as separate packages. These are not being worked on or maintained by anyone either, but they are the latest official releases that anyone interested should use. The generalised trie stuff is what Jamie Brandon is working on for his GSOC project. The relevant packages are: Data-Tree-AVL 0.4 Data-COrdering 0.4 Data-Trie-General 0.4 collections-base-instances 0.4 collections-rangedsets-instances 0.4 collections-api 0.4 enumsets 0.4 collections-avl 0.4 Data-Trie-General-OrdGT 0.4 collections 0.4 Regards -- Adrian Hey From lemming at henning-thielemann.de Wed Jun 18 10:42:17 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Jun 18 10:34:09 2008 Subject: Broken packages on hackage In-Reply-To: <20080618074404.GA7048@celeborn> References: <20080617232606.GN19304@scytale.galois.com> <20080618074404.GA7048@celeborn> Message-ID: On Wed, 18 Jun 2008, Spencer Janssen wrote: >> storablevector -- QC arbitrary missing Control.Monad.Instances > > Builds fine here. However, the tests should not build for a Hackage release, > I'll look into this. Sorry Spencer, I added them - because it worked and was convenient. We could comment it out for Hackage. From dons at galois.com Wed Jun 18 11:33:39 2008 From: dons at galois.com (Don Stewart) Date: Wed Jun 18 11:25:53 2008 Subject: Broken packages on hackage In-Reply-To: References: <20080617232606.GN19304@scytale.galois.com> Message-ID: <20080618153339.GA23761@scytale.galois.com> I managed to build dataenc, so whatever the problem was, it was temporary. Sorry for the false positive. -- Don magnus: > I see dataenc is in the list below, which I found a bit surprising since > it does indeed build fine with the split up base package. However, when I > hacked its cabal file I thought it made more sense to use a flag called > large_base which defaults to false, rather than a flag called small-base > which defaults to true. If the consensus is to use small-base I'll be > happy to change it. > > /M > > On Wed, Jun 18, 2008 at 12:26 AM, Don Stewart <[1]dons@galois.com> wrote: > > Just did a full run over hackage, building packages with ghc 6.8.2, > bytestring [2]0.9.0.1 and cabal [3]1.4.1.. > > Several hundred packages built fine. > The majority are relatively easy to fix, if the upstream authors > can be contacted. > > The following could be marked broken, if we could do that. > > Easy: > Doesn't support small-base: > AGI > libxml > newbinary > openafp > StategyLib > Catch > classify > collections > compression > dataenc > derangement > hogg > hsc2hs 2006 > hslogger > hsns > hsql > lambdaFeed > metaplug > mime-string > pointfree > sat > soegtk > sparsecheck > special-functors (needs base<2 !) > suffixtree > th-lift > torrent > udcode > > More work: > Broken: > BerkleyDB -- missing extra-libs at least > dbus -- various things. > encode -- type errors > flippi -- depends on unreleased cgi version > finance-treasury -- needs new hxt-filter (author has patch) > HsPerl5-0.0.4 -- cc1: error: unrecognized command line > option "-Wl" > HsSVN -- missing extra-libraries: svn > Monadius -- missing: extra-libraries: glut > shu-thing -- missing: extra-libraries: glut > postgresql -- Too many parameters for class > `MonadDatabase' > probabilitymonads -- Illegal instance declaration > sdl -- gcc: unrecognized option '-rpath' > baskell -- missing modules > bot -- Duplciate Instance > cabal-setup -- type error > cabal-tests -- Could not find module `Tests' > cabalrpmdeps -- cabal type error > clustertools -- missing constructors > debian -- cabal type error > dephhd -- type error > hs-pgms -- missing modules > network-rpca -- type error > parsely -- missing -XFunctionalDependencies > ports -- cpp errro > postmaster -- (.text+0x1442): undefined reference to > `EVP_mdc2' ? > reify -- linker error reifyC > roguestar -- Could not find module > `Keymaps.CommonKeymap' > slackbuild -- cabal innards > lax -- cabal innards > lhs2tex -- cabal innards > rss -- needs haxml 1.3..<1.4 > scenegraph -- source for > Graphics.SceneGraph.SimpleViewport > shell-pipe -- `GHC.Handle' does not export `openFd' > srcinst -- module Dpkg missing > state -- Setup: COPYRIGHT: copyFile: does not exist > storablevector -- QC arbitrary missing > Control.Monad.Instances > truelevel -- Could not find module `TrueLevelArgs' > type-int -- Could not find module `Data.Type.Sign' > > GHC error: > WURFL --stack overflow on large file > cedict -- stack oflow on 32k large list > cpuid -- Error: suffix or operands invalid for `test' > > Depends on something hidden: > HDBC-postgresql-1.1.4.0, Cabal version: >=1.2 && <1.3 > Takusen > cabal-upload > regex-dfa > regex-parsec > regex-pcre > regex-tdfa > > -- Don > _______________________________________________ > Libraries mailing list > [4]Libraries@haskell.org > [5]http://www.haskell.org/mailman/listinfo/libraries > > References > > Visible links > 1. mailto:dons@galois.com > 2. http://0.9.0.1/ > 3. http://1.4.1./ > 4. mailto:Libraries@haskell.org > 5. http://www.haskell.org/mailman/listinfo/libraries From v.dijk.bas at gmail.com Wed Jun 18 12:16:21 2008 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Wed Jun 18 12:08:15 2008 Subject: Generic tries (long) In-Reply-To: <10ed1a750806161228t12b974dx18395853e2b9e5f2@mail.gmail.com> References: <10ed1a750806161228t12b974dx18395853e2b9e5f2@mail.gmail.com> Message-ID: On Mon, Jun 16, 2008 at 9:28 PM, Jamie Brandon wrote: > Hi, I'm writing a library for generic tries for the Summer of Code. > The main point of this post is to get some feedback on the api but > I'll briefly explain the idea. > > The point of a trie is to exploit the recursive nature of ADTs to save > on expensive key comparisons and reduce space consumption. Hinze' > original formulation is very elegant but results in very deep > structures and is fairly inefficient. The normal trie optimisations > (concatenating singleton maps, mainly) cant be applied to the generic > version. > > I intend instead to encode ADTs as lists. This encoding can range from > a simple walk of the ADT to creating a compressed, bit packing > representation. The resulting tradeoff between encoding time and space > usage should make the design fairly flexible. This will look something > like: > > class Serial k where > > -- | Flattened form of key consists of a list of Nodes > -- Node will be Int or UArray Int for compressed implementations > type Node k > > -- | Flatten to a list of Nodes > serialise :: k -> [Node k] > > -- | Reconstruct from a list of Nodes > unserialise :: [Node k] -> k > > The api below is mostly cribbed from Adrian Hey's initial design. > Guarantees about ordering will probably vary between maps. All > ascending have descending version too. Strict versions of functions > will be written where appropriate, I've omitted them here for brevity. > Key reconstruction is likely to be expensive so it may make more sense > to seperate foldrKeys and friends into a seperate class. > > Adrian has written instance of GMap for lists, UInts and Ord types so > I can declare > instance (Serial k) => GMap (ListGMap (Node k)) k where ... etc > > I should have a spot on code.haskell.org soon, at which point I'll put > up a Haddock page with the most up to date version of the api. > > class GMap map where > > type k > > -- | The empty map. > empty :: map a > > -- | Create a map with a single association. > singleton :: k -> a -> map a > > -- | Create a map from a list of associations which /must/ be in > ascending order of keys > -- (with /no/ duplicate keys). If in doubt use one of the safer (but > slower) 'fromAssocs' functions. > fromAssocsAscending :: [(k,a)] -> map a > > -- | Return 'True' if the map contains no associations. > isEmpty :: map a -> Bool > > -- | Return 'True' if the map contains exactly one association. > isSingleton :: map a -> Bool > > -- | Return the value associated with the supplied key (if any). > lookup :: k -> map a -> Maybe a > > -- | Insert a new association in the map if there is currently no > value associated with the key. > -- If there is a value associated with the key then replace it with > the result of > -- applying the supplied function to that value. > insert :: (a -> a) -> k -> a -> map a -> map a > > -- | Delete the association for the supplied key (if any). > delete :: k -> map a -> map a > > -- | This is a combined insert\/modify\/delete operation. The argument > to the supplied function > -- is ('Just' a) if there is a value (a) associated with the supplied > key, otherwise 'Nothing'. > -- If the return value is ('Just' a'), a' becomes the new value > associated with the supplied key. > -- If the return value is 'Nothing', the association for the supplied > key (if any) is deleted. > alter :: (Maybe a -> Maybe a) -> k -> map a -> map a > > -- | Evaluate the union of two maps. If the maps contain common keys > then combine the > -- values associated with those keys using the supplied function. The > value arguments > -- to this function are supplied in the same order as the map arguments. > union :: (a -> a -> a) -> map a -> map a -> map a > > -- | Evaluate the intersection of two maps, combining common > associations using the supplied function. > intersection :: (a -> b -> c) -> map a -> map b -> map c > > -- | Evaluate the difference between two maps. For any key occuring in > the second map, > -- the corresponding association (if any) is deleted from the first map. > -- The associated values in the second map are irrelevant. > difference :: map a -> map b -> map a > > -- | Returns true if the keys in the first map are a subset of the > keys in the second map. > -- (This includes the case where the key sets are identical). Note > that this function does > -- not examine the associated values (which are irrelevant). See > 'isSubmapOf' if you > -- do want associated values examined. > isSubsetOf :: map a -> map b -> Bool > > -- | Returns true if the keys in the first map are a subset of the > keys in the second map > -- and the corresponding function always returns true when applied to > the values associated > -- with matching keys. > isSubmapOf :: (a -> b -> Bool) -> map a -> map b -> Bool > > -- | Apply the supplied function to every associated value in the map. > map :: (a -> b) -> map a -> map b > > -- | Apply the supplied function to every association in the map, and > use the result > -- as the new associated value for the corresponding key. > mapWithKey :: (k -> a -> b) -> map a -> map b > > -- | Delete associations for which the supplied predicate returns > 'False' when applied to > -- the associated value. > filter :: (a -> Bool) -> map a -> map a > > -- | Fold right over the list of elements in ascending order of keys. > -- See 'foldrElemsAscending'' for a strict version of this function. > foldrElemsAscending :: (a -> b -> b) -> map a -> b -> b > > -- | Fold right over the list of keys in ascending order. > -- See 'foldrKeysAscending'' for a strict version of this function. > foldrKeysAscending :: (k -> b -> b) -> map a -> b -> b > > -- | Fold right over the list of associations in ascending order of keys. > -- See 'foldrAssocsAscending'' for a strict version of this function. > foldrAssocsAscending :: (k -> a -> b -> b) -> map a -> b -> b > > -- | Fold over elements in un-specified order using /unboxed/ Int > accumulator (with GHC). > -- Defaults to boxed Int for other Haskells. Typically used for > counting functions. > -- Implementations are free to traverse the map in any order. > -- The folded function is always applied strictly. > foldElemsUINT :: (a -> UINT -> UINT) -> map a -> UINT -> UINT > > In addition there a few functions which are useful for groups of maps > or nested maps. > > -- | Add the number of associations in a map to the supplied /unboxed/ > Int (with GHC). > -- Defaults to boxed Int for other Haskells. > addSize :: map a -> UINT -> UINT > > -- | Find the value associated with the supplied key (if any) and > return the result > -- of applying the supplied continuation function to that value. > Useful for nested lookup. > lookupCont :: (a -> Maybe b) -> k -> map a -> Maybe b > > -- | Reject empty maps (return Nothing). > nonEmpty :: map a -> Maybe (map a) > > The following functions are useful internally as most of the maps are > defined in terms of simpler maps. Also see this thread on the need for > unionMaybe. > > -- | Similar to 'insert', but the association is deleted if the > supplied function returns 'Nothing'. > -- (The supplied function is always applied strictly.) > insertMaybe :: (a -> Maybe a) -> k -> a -> map a -> map a > > -- | Find the value associated with the supplied key (if any) and > apply the supplied function > -- to that value. Delete the association if the result is 'Nothing'. > Replace the old value with > -- the new value if the result is ('Just' something). > -- (The supplied function is always applied strictly.) > deleteMaybe :: (a -> Maybe a) -> k -> map a -> map a > > -- | Evaluate the union of two maps, but delete combined associations > from the result map > -- if the combining function returns 'Nothing'. > -- (The combining function is always applied strictly.) > unionMaybe :: (a -> a -> Maybe a) -> map a -> map a -> map a > > -- | Evaluate the intersection of two maps, but delete combined > associations from the result map > -- if the combining function returns 'Nothing'. > -- (The combining function is always applied strictly.) > intersectionMaybe :: (a -> b -> Maybe c) -> map a -> map b -> map c > > -- | Difference with a combining function. If the combining function returns > -- @Just a@ then the corresponding association is not deleted from the > result map > -- (it is retained with @a@ as the associated value). > differenceMaybe :: (a -> b -> Maybe a) -> map a -> map b -> map a > > -- | Apply the supplied function to every associated value in the map. > -- If the result is 'Nothing' then the delete the corresponding association. > -- (The supplied function is always applied strictly.) > mapMaybe :: (a -> Maybe b) -> map a -> map b > > Thanks > > Jamie > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > Just a thought: why not have: import Data.Traversable class Traversable map => GMap map where ... (remove 'map') ... Because all maps ought to be traversable. See: http://haskell.org/ghc/docs/latest/html/libraries/base/Data-Traversable.html Bas From dons at galois.com Wed Jun 18 16:11:25 2008 From: dons at galois.com (Don Stewart) Date: Wed Jun 18 16:03:17 2008 Subject: Package spam :-) In-Reply-To: <4858F398.20708@iee.org> References: <4858F398.20708@iee.org> Message-ID: <20080618201125.GG24043@scytale.galois.com> As author Adrian, you can ask to have them removed. Gwern: do not upload other people's packages, if they're active! It is impolite, and leads to far too much broken code. In particular, doing random forks of existing packages with their own matainers *is not helpful* -- it just leads to broken, unmaintained code. Adrian, as these packages simply fork needlessly, or aren't of suitable quality, I think you can ask Ross to remove them. ahey: > Hello folks in general and GwernBranwen in particular :-) > > I don't want to seem ungratful, but I see a lot of the old "new" > collections repository has been uploaded to Hackage as separate packages > but it really shouldn't be there IMHO. AFAIK most of this stuff has > never been properly tested and is in any case not being actively worked > on or maintained any more. > > AvlTree and COrdering have been thoroughly tested and are already in > Hackage as separate packages. These are not being worked on or > maintained by anyone either, but they are the latest official releases > that anyone interested should use. > > The generalised trie stuff is what Jamie Brandon is working on for his > GSOC project. > > The relevant packages are: > > Data-Tree-AVL 0.4 > Data-COrdering 0.4 > Data-Trie-General 0.4 > collections-base-instances 0.4 > collections-rangedsets-instances 0.4 > collections-api 0.4 > enumsets 0.4 > collections-avl 0.4 > Data-Trie-General-OrdGT 0.4 > collections 0.4 > -- Don From dons at galois.com Wed Jun 18 16:26:37 2008 From: dons at galois.com (Don Stewart) Date: Wed Jun 18 16:18:52 2008 Subject: Broken packages on hackage In-Reply-To: <20080618074404.GA7048@celeborn> References: <20080617232606.GN19304@scytale.galois.com> <20080618074404.GA7048@celeborn> Message-ID: <20080618202637.GI24043@scytale.galois.com> sjanssen: > On Tue, Jun 17, 2008 at 04:26:06PM -0700, Don Stewart wrote: > > Just did a full run over hackage, building packages with ghc 6.8.2, > > bytestring 0.9.0.1 and cabal 1.4.1.. > > > > Several hundred packages built fine. > > The majority are relatively easy to fix, if the upstream authors > > can be contacted. > > > > The following could be marked broken, if we could do that. > > I tried building a few of these packages, and my results mostly agree. > > > dataenc > > dataenc 0.11 works for me. Yep, my script was building the wrong version. > > > hslogger > > hslogger 1.0.5 works for me (in fact all of the versions on hackage seem to > support split base). Ah, it was hslogger4j that failed, due to split-base issues. > > Monadius -- missing: extra-libraries: glut > > shu-thing -- missing: extra-libraries: glut > > Both of these build and run here. I don't understand why they should have > "extra-libraries: glut", don't the extra-libraries belong in the GLUT package > instead? Good point. Adding 'extra-libraries: glut' to OpenGL.cabal doesn't seem to fix it though. Any thoughts? > > storablevector -- QC arbitrary missing Control.Monad.Instances > > Builds fine here. However, the tests should not build for a Hackage release, > I'll look into this. Yep, the tests were failing From ahey at iee.org Wed Jun 18 17:13:23 2008 From: ahey at iee.org (Adrian Hey) Date: Wed Jun 18 17:05:36 2008 Subject: Package spam :-) In-Reply-To: <20080618201125.GG24043@scytale.galois.com> References: <4858F398.20708@iee.org> <20080618201125.GG24043@scytale.galois.com> Message-ID: <48597A73.6050900@iee.org> Hello Don, I didn't write all of them, there are other authors involved so I can't say for sure what their plans may be. But I'm pretty sure that if they're still interested and thought the code fit for release they'd put it in Hackage themselves. Regards -- Adrian Hey Don Stewart wrote: > As author Adrian, you can ask to have them removed. > > Gwern: do not upload other people's packages, if they're active! It is > impolite, and leads to far too much broken code. > > In particular, doing random forks of existing packages with their own > matainers *is not helpful* -- it just leads to broken, unmaintained code. > > Adrian, as these packages simply fork needlessly, or aren't of suitable > quality, I think you can ask Ross to remove them. > > ahey: >> Hello folks in general and GwernBranwen in particular :-) >> >> I don't want to seem ungratful, but I see a lot of the old "new" >> collections repository has been uploaded to Hackage as separate packages >> but it really shouldn't be there IMHO. AFAIK most of this stuff has >> never been properly tested and is in any case not being actively worked >> on or maintained any more. >> >> AvlTree and COrdering have been thoroughly tested and are already in >> Hackage as separate packages. These are not being worked on or >> maintained by anyone either, but they are the latest official releases >> that anyone interested should use. >> >> The generalised trie stuff is what Jamie Brandon is working on for his >> GSOC project. >> >> The relevant packages are: >> >> Data-Tree-AVL 0.4 >> Data-COrdering 0.4 >> Data-Trie-General 0.4 >> collections-base-instances 0.4 >> collections-rangedsets-instances 0.4 >> collections-api 0.4 >> enumsets 0.4 >> collections-avl 0.4 >> Data-Trie-General-OrdGT 0.4 >> collections 0.4 >> > > > -- Don > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > From jcb73 at cam.ac.uk Wed Jun 18 18:16:09 2008 From: jcb73 at cam.ac.uk (Jamie Brandon) Date: Wed Jun 18 18:07:59 2008 Subject: Generic tries (long) In-Reply-To: References: <10ed1a750806161228t12b974dx18395853e2b9e5f2@mail.gmail.com> Message-ID: <10ed1a750806181516o1e46cd7fp7d288631f20f9bd4@mail.gmail.com> Ive put up the haddock api at http://code.haskell.org/gmap/api/GMap.html The interface is now split into GMap which make no guarantees on ordering and OrderedGMap which provides a compareKey function as well as ordered folds etc. > Because all maps ought to be traversable. Thats a good point. Traversable requires Foldable. Do people expect Foldable to imply some ordering? I can put it into OrderedGMap at least. Jamie From frederik at ofb.net Wed Jun 18 18:37:00 2008 From: frederik at ofb.net (Frederik Eaton) Date: Wed Jun 18 18:28:49 2008 Subject: Proposal: overhaul System.Process In-Reply-To: <1211758855.5824.570.camel@localhost> References: <480E6478.5040209@gmail.com> <17463614.post@talk.nabble.com> <1211758855.5824.570.camel@localhost> Message-ID: <17993548.post@talk.nabble.com> I'm sorry for my late reply. This all sounds reasonable. My only concerns are that deprecating the old interfaces seems like a declaration of intent to eventually remove them. I believe that to the extent possible, library development should start with simple low-level interfaces which expose OS-level functionality in a straightforward manner, and then build on top of them. I realise that running processes is an especially difficult area, because different operating systems have different interfaces, there is the possibility of pipes and so forth. Perhaps this is why we have gone through multiple iterations of process-running APIs in the Haskell standard libraries. But I think that especially low-level interfaces like these should be created with the understanding that they will stay around forever, even if the cumulative result is slightly ugly. That can be an incentive to get them right the first time. In my mind, if 'createProcess' could not be implemented via the old interfaces, then that means they weren't low-level enough to start with. And in that case, we should be working on providing better low-level interfaces, rather than new high-level ones (I think 'createProcess' is slightly higher-level than 'runProcess' because it has a notion of a shell, pipes, fancy data structures, etc.). On the other hand, if 'runProcess' and friends were sufficient to implement 'createProcess', then that means they provided a satisfactory low-level foundation. And I think low-level interfaces are built upon, not deprecated. Duncan Coutts wrote: > > The proposal is to deprecate several functions but not to remove > anything. The decision to remove anything is independent. > > One this issue, one thing that I think may help is to have a period > where the deprecated functions still exist but are removed from the > documentation. The rationale is that one of the main reasons for > removing functions that are essentially duplicated by newer variants is > because they clutter the API docs. > > So the deprecation cycle would be something like: > > 1. normal > 2. deprecated and still documented > 3. deprecated and removed from documentation > 4. removed > > Another thing that would help is if haddock marked deprecated functions > as such and kept them in a separate section of the index, at least in > the synopsis. It should be easy for haddock 2.x to find deprecated > functions since it can just look at the pragmas which are presumably > preserved by the GHC api. > -- View this message in context: http://www.nabble.com/Proposal%3A-overhaul-System.Process-tp16844161p17993548.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. From droundy at darcs.net Wed Jun 18 18:46:49 2008 From: droundy at darcs.net (David Roundy) Date: Wed Jun 18 18:38:40 2008 Subject: Proposal: overhaul System.Process In-Reply-To: <17993548.post@talk.nabble.com> References: <480E6478.5040209@gmail.com> <17463614.post@talk.nabble.com> <1211758855.5824.570.camel@localhost> <17993548.post@talk.nabble.com> Message-ID: <20080618224648.GU32397@darcs.net> On Wed, Jun 18, 2008 at 03:37:00PM -0700, Frederik Eaton wrote: > > I'm sorry for my late reply. This all sounds reasonable. My only concerns are > that deprecating the old interfaces seems like a declaration of intent to > eventually remove them. I believe that to the extent possible, library > development should start with simple low-level interfaces which expose > OS-level functionality in a straightforward manner, and then build on top of > them. I realise that running processes is an especially difficult area, > because different operating systems have different interfaces, there is the > possibility of pipes and so forth. Perhaps this is why we have gone through > multiple iterations of process-running APIs in the Haskell standard > libraries. But I think that especially low-level interfaces like these > should be created with the understanding that they will stay around forever, > even if the cumulative result is slightly ugly. That can be an incentive to > get them right the first time. > > In my mind, if 'createProcess' could not be implemented via the old > interfaces, then that means they weren't low-level enough to start with. And > in that case, we should be working on providing better low-level interfaces, > rather than new high-level ones (I think 'createProcess' is slightly > higher-level than 'runProcess' because it has a notion of a shell, pipes, > fancy data structures, etc.). On the other hand, if 'runProcess' and friends > were sufficient to implement 'createProcess', then that means they provided > a satisfactory low-level foundation. And I think low-level interfaces are > built upon, not deprecated. No, createProcess is more low-level than the previous interface, which is why it can't be implemented using the previous interfaces, but rather they can be implemented using createProcess. Which is why they can be deprecated, although I'd hope they won't be removed for at least a couple more ghc releases after createProcess is introduced. David From isaacdupree at charter.net Wed Jun 18 19:15:45 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Wed Jun 18 19:07:32 2008 Subject: Generic tries (long) In-Reply-To: <10ed1a750806181516o1e46cd7fp7d288631f20f9bd4@mail.gmail.com> References: <10ed1a750806161228t12b974dx18395853e2b9e5f2@mail.gmail.com> <10ed1a750806181516o1e46cd7fp7d288631f20f9bd4@mail.gmail.com> Message-ID: <48599721.1060403@charter.net> Jamie Brandon wrote: > Ive put up the haddock api at http://code.haskell.org/gmap/api/GMap.html > > The interface is now split into GMap which make no guarantees on > ordering and OrderedGMap which provides a compareKey function as well > as ordered folds etc. > >> Because all maps ought to be traversable. > > Thats a good point. Traversable requires Foldable. Do people expect > Foldable to imply some ordering? I can put it into OrderedGMap at > least. Foldable does, trivially, imply ordering: "fold" can distinguish the order. So you might have to be careful about breaking referential transparency (at least if you want "==" GMaps to always be extensionally equivalent). But obviously a container without some concept of ordering will probably not be in any particularly *meaningful* order! It should still be Foldable if there's no reason not to (which is useful at least for commutative+associative ops like "+"). All IMHO. -Isaac From frederik at ofb.net Wed Jun 18 19:22:24 2008 From: frederik at ofb.net (Frederik Eaton) Date: Wed Jun 18 19:14:14 2008 Subject: Proposal: overhaul System.Process In-Reply-To: <20080618224648.GU32397@darcs.net> References: <480E6478.5040209@gmail.com> <17463614.post@talk.nabble.com> <1211758855.5824.570.camel@localhost> <17993548.post@talk.nabble.com> <20080618224648.GU32397@darcs.net> Message-ID: <17994178.post@talk.nabble.com> David Roundy-2 wrote: > > No, createProcess is more low-level than the previous interface, which > is why it can't be implemented using the previous interfaces, but > rather they can be implemented using createProcess. Which is why they > can be deprecated, although I'd hope they won't be removed for at > least a couple more ghc releases after createProcess is introduced. > In what way is 'createProcess' more low-level than the previous interfaces? In any case, it still makes sense to me to keep the previous interfaces around indefinitely - even if they have to be redefined in terms of 'createProcess'. But 'createProcess' seems quite a bit more high-level than the others. It seems to combine a lot of different POSIX functions like 'exec' and 'system' and 'pipe' which could all be exposed individually through a simpler API. Frederik -- View this message in context: http://www.nabble.com/Proposal%3A-overhaul-System.Process-tp16844161p17994178.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. From john at repetae.net Wed Jun 18 19:39:26 2008 From: john at repetae.net (John Meacham) Date: Wed Jun 18 19:31:17 2008 Subject: Proposal: overhaul System.Process In-Reply-To: <17994178.post@talk.nabble.com> References: <480E6478.5040209@gmail.com> <17463614.post@talk.nabble.com> <1211758855.5824.570.camel@localhost> <17993548.post@talk.nabble.com> <20080618224648.GU32397@darcs.net> <17994178.post@talk.nabble.com> Message-ID: <20080618233926.GG12977@sliver.repetae.net> On Wed, Jun 18, 2008 at 04:22:24PM -0700, Frederik Eaton wrote: > In what way is 'createProcess' more low-level than the previous interfaces? > In any case, it still makes sense to me to keep the previous interfaces > around indefinitely - even if they have to be redefined in terms of > 'createProcess'. But 'createProcess' seems quite a bit more high-level than > the others. It seems to combine a lot of different POSIX functions like > 'exec' and 'system' and 'pipe' which could all be exposed individually > through a simpler API. I think another issue here is where the OS abstraction happens. Opaquely in libraries, or on top of OS primitives themselves in haskell. Personally, I would like to see the OS abstraction happen in exposed haskell libraries. as in, POSIX, Win32, SunOS, etc.. libraries in haskell built on exposed haskell primitives, and things like 'createProcess' on top of them. Of course, the implementation of createProcess will have to conform to whatever is available on the current system (which is in not as simple as posix vs windows, autoconf-esque feature checks will be needed) but I'd rather have that done in haskell than C or opaquely in a library. This is more an opinion on implementation than standardization. I think it is fully fine to provide standard high level interfaces before the low level ones get worked out, as long as the low level ones arn't excluded in favor of just the high level interface. John -- John Meacham - ?repetae.net?john? From ross at soi.city.ac.uk Wed Jun 18 20:31:16 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Jun 18 20:23:10 2008 Subject: Package spam :-) In-Reply-To: <20080618201125.GG24043@scytale.galois.com> References: <4858F398.20708@iee.org> <20080618201125.GG24043@scytale.galois.com> Message-ID: <20080619003116.GA7598@soi.city.ac.uk> On Wed, Jun 18, 2008 at 01:11:25PM -0700, Don Stewart wrote: > As author Adrian, you can ask to have them removed. > > Gwern: do not upload other people's packages, if they're active! It is > impolite, and leads to far too much broken code. > > In particular, doing random forks of existing packages with their own > matainers *is not helpful* -- it just leads to broken, unmaintained code. I don't mind forks, as long as they have a maintainer and a different name. My problem with these packages is that they specify maintainers, but the uploaded versions appear not to have been created by the named maintainers. If a package names a maintainer, I think we should be able to assume that whatever was uploaded is that person's approved version, packaging and all. From droundy at darcs.net Wed Jun 18 21:55:55 2008 From: droundy at darcs.net (David Roundy) Date: Wed Jun 18 21:47:45 2008 Subject: Proposal: overhaul System.Process In-Reply-To: <17994178.post@talk.nabble.com> References: <480E6478.5040209@gmail.com> <17463614.post@talk.nabble.com> <1211758855.5824.570.camel@localhost> <17993548.post@talk.nabble.com> <20080618224648.GU32397@darcs.net> <17994178.post@talk.nabble.com> Message-ID: <20080619015555.GV32397@darcs.net> On Wed, Jun 18, 2008 at 04:22:24PM -0700, Frederik Eaton wrote: > David Roundy-2 wrote: > > No, createProcess is more low-level than the previous interface, which > > is why it can't be implemented using the previous interfaces, but > > rather they can be implemented using createProcess. Which is why they > > can be deprecated, although I'd hope they won't be removed for at > > least a couple more ghc releases after createProcess is introduced. > > In what way is 'createProcess' more low-level than the previous interfaces? The easiest sense in which it's more low-level is that the previous two commands runProcess and runInteractiveProcess can both be implemented using createProcess, but not the other way around. New API: (a subset thereof, actually) createProcess :: CreateProcess -> IO (Maybe Handle, Maybe Handle, Maybe Handle, ProcessHandle) data CreateProcess = CreateProcess { cmdspec :: CmdSpec cwd :: (Maybe FilePath) env :: (Maybe [(String, String)]) std_in :: StdStream std_out :: StdStream std_err :: StdStream close_fds :: Bool } Old API: runProcess :: FilePath -> [String] -> Maybe FilePath -> Maybe [(String, String)] -> Maybe Handle -> Maybe Handle -> Maybe Handle -> IO ProcessHandle runInteractiveProcess :: FilePath -> [String] -> Maybe FilePath -> Maybe [(String, String)] -> IO (Handle, Handle, Handle, ProcessHandle) In the old API, you are required to either use preexisting handles for each of stdin/stdout/stderr (possibly allowing the child process to inherit some or all of them), *or* create new pipes for all three. You might consider trying to implement runInteractiveProcess using runProcess (you certainly can't do the opposite) by setting up pipes and passing them to runProcess, but there's no portable function that can be used to do this, so you'd be out of luck. You'd be stuck doing what darcs has long done: write to temporary files on disk, which is totally braindead. createProcess is (so far as I can tell) the lowest-level *portable* Haskell API for spawning processes that has yet been proposed, in the sense that there are no other proposed functions that could be used to implement createProcess, and no other proposed functions that cannot be implemented using createProcess. -- David Roundy Department of Physics Oregon State University From cjs at starling-software.com Wed Jun 18 23:57:58 2008 From: cjs at starling-software.com (Curt Sampson) Date: Wed Jun 18 23:49:59 2008 Subject: Proposal: overhaul System.Process In-Reply-To: <17993548.post@talk.nabble.com> References: <480E6478.5040209@gmail.com> <17463614.post@talk.nabble.com> <1211758855.5824.570.camel@localhost> <17993548.post@talk.nabble.com> Message-ID: <20080619035758.GC11561@lucky.cynic.net> On 2008-06-18 15:37 -0700 (Wed), Frederik Eaton wrote: > My only concerns are that deprecating the old interfaces seems like a > declaration of intent to eventually remove them. Just as one opinion, I prefer that old interfaces get removed. I have no problem updating code to deal with this kind of stuff, and the cost of that is easily paid off (for me) in the benefits I get from having simple interfaces available. I found Java's libraries quite trying due to the amount of cruft one was always wading through. That said, I think it's a *very* good idea to keep old versions of libraries and compilers available for download, for those folks that want to run a program written for an older system and don't feel up to tweaking the code to run on a newer one. cjs -- Curt Sampson +81 90 7737 2974 Mobile sites and software consulting: http://www.starling-software.com From duncan.coutts at worc.ox.ac.uk Thu Jun 19 06:32:07 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jun 19 06:19:25 2008 Subject: Proposal: overhaul System.Process In-Reply-To: <17994178.post@talk.nabble.com> References: <480E6478.5040209@gmail.com> <17463614.post@talk.nabble.com> <1211758855.5824.570.camel@localhost> <17993548.post@talk.nabble.com> <20080618224648.GU32397@darcs.net> <17994178.post@talk.nabble.com> Message-ID: <1213871527.15010.868.camel@localhost> On Wed, 2008-06-18 at 16:22 -0700, Frederik Eaton wrote: > In any case, it still makes sense to me to keep the previous interfaces > around indefinitely - even if they have to be redefined in terms of > 'createProcess'. I wouldn't mind keeping them indefinitely (especially since they're just simple instances of createProcess) so long as they eventually get removed from the documentation (or at a very minimum, removed to a separate page where I don't have to look at them). I think that would also satisfy Curt and his point about the cruft in the Java's libraries. Keeping stuff around so you don't break old programs is fine and great. Making the documentation large and the api look very wide and not knowing which functions to pick is actively bad. Duncan From duncan.coutts at worc.ox.ac.uk Thu Jun 19 06:35:37 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jun 19 06:22:43 2008 Subject: Package spam :-) In-Reply-To: <20080619003116.GA7598@soi.city.ac.uk> References: <4858F398.20708@iee.org> <20080618201125.GG24043@scytale.galois.com> <20080619003116.GA7598@soi.city.ac.uk> Message-ID: <1213871737.15010.870.camel@localhost> On Thu, 2008-06-19 at 01:31 +0100, Ross Paterson wrote: > On Wed, Jun 18, 2008 at 01:11:25PM -0700, Don Stewart wrote: > > As author Adrian, you can ask to have them removed. > > > > Gwern: do not upload other people's packages, if they're active! It is > > impolite, and leads to far too much broken code. > > > > In particular, doing random forks of existing packages with their own > > matainers *is not helpful* -- it just leads to broken, unmaintained code. > > I don't mind forks, as long as they have a maintainer and a different > name. > > My problem with these packages is that they specify maintainers, but > the uploaded versions appear not to have been created by the named > maintainers. > > If a package names a maintainer, I think we should be able to assume > that whatever was uploaded is that person's approved version, packaging > and all. I agree. I think we should get round to writing this down as a hackage policy and getting a quick show of hands on this list. Duncan From apfelmus at quantentunnel.de Thu Jun 19 06:33:58 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Thu Jun 19 06:26:05 2008 Subject: Generic tries (long) In-Reply-To: <10ed1a750806181516o1e46cd7fp7d288631f20f9bd4@mail.gmail.com> References: <10ed1a750806161228t12b974dx18395853e2b9e5f2@mail.gmail.com> <10ed1a750806181516o1e46cd7fp7d288631f20f9bd4@mail.gmail.com> Message-ID: Jamie Brandon wrote: > Ive put up the haddock api at http://code.haskell.org/gmap/api/GMap.html I have a few comments on the proposed API. 1) Some terminology seems queer to me. In particular, I don't like the terms "assoc" and "association" in the documentation. The Data.Map documentation uses "key/value pair" or just "key" and "value"/"element" instead, which I think is much better. For instance: "Insert a new association in the map" :( "Insert a new key and value in the map." :) Also, I like fromList better than fromAssocs . 2) Don't use Int# , looks like a premature optimization to me. Furthermore, I'd change the queer addSize to simply size :: map a -> Int 3) insert is strange. Why not use the convention in Data.Map, name it insertWith and have insert :: k -> a -> map a -> map a instead? Similar for union . 4) Most functions, in particular the ..Maybe variants have fixed default definitions. I wouldn't include them in the class. How about a minimal class interface along the lines of class GMap map k | map -> k where empty :: map a null :: map a -> Bool lookup :: k -> map a -> Maybe a alter :: (Maybe a -> Maybe a) -> k -> map a -> map a merge :: (k -> Maybe a -> Maybe b -> Maybe c) -> map a -> map b -> map c fromList :: [(k,a)] -> map a toList :: map a -> [(k,a)] instance Functor map where ... and implementing the various variants as normal polymorphic functions? Like insert k a = alter (const $ Just a) k singleton k a = insert k a empty IMHO, having a few "flag" functions like difference :: k -> Maybe a -> Maybe b -> Maybe b union :: k -> Maybe a -> Maybe a -> Maybe a intersect :: k -> Maybe a -> Maybe a -> Maybe a that can be plugged into merge is much nicer than having to remember/lookup all the ..Maybe and whatnot'' variants. 5) I think the following functions are queer lookupCont f k m = lookup k m >>= f pair k1 k2 = if k1 == k2 then Nothing else Just $ \a1 a2 -> insert k1 a1 (insert k2 a2 empty) What use is pair ? I'd definitively put them outside the class if not remove them entirely. 6) status is an interesting idea with a meaningless name. Don't you have a name that is more to the point, that expresses the nub (pun intended) of what status does? 7) I'm overwhelmed by the many foldr...Asc/Descending functions. They all can be expressed in terms of toListAsc and toListDesc and I don't think that "marginally faster" is a reason not to do so. I'd throw away the from...L functions, too. Regards, apfelmus From ahey at iee.org Thu Jun 19 08:20:15 2008 From: ahey at iee.org (Adrian Hey) Date: Thu Jun 19 08:12:49 2008 Subject: Generic tries (long) In-Reply-To: <10ed1a750806181516o1e46cd7fp7d288631f20f9bd4@mail.gmail.com> References: <10ed1a750806161228t12b974dx18395853e2b9e5f2@mail.gmail.com> <10ed1a750806181516o1e46cd7fp7d288631f20f9bd4@mail.gmail.com> Message-ID: <485A4EFF.2060901@iee.org> Hello Jamie, Jamie Brandon wrote: > Ive put up the haddock api at http://code.haskell.org/gmap/api/GMap.html The ordering issue is still bothering the heck out of me. With the above OrderedGMap class (only) we lose the ability to use tries for sorting faster than the usual O(n . log n), which seems a real shame. Especially as it means folk will often end up having to do a O(n . log n) sort stage on the data anyway (without the benefit of "trie acceleration" presumably). So I think I would really like to see a subclass that *does* guarantee Ordering that is consistent with Ord. The question of how instances of that subclass are produced/derived or whatever is still open. Automated trie deriving could presumably only guarantee ordering consistent with a (wholly) derived Ord instance, not hand written Ord instances. I also find myself wondering if we really need to make the distinction between Map implementations that really can make *no* guarantee about consiststent ordering and maps that do guarantee consistent ordering (that is inconsistent with Ords ordering). I'm struggling to imagine any decent Map implementation that falls into the former category (I.E. is an instance of GMap *only*). I guess hash tables that used a linear list for each bucket are one possible example, hmm.. Also, a minor naming niggle with the folds in the GMap class. I think these should have a "fold" prefix only (not "foldr"), as there is no implied ordering guarantee. I'm also wondering if we should at least have an Eq constraint on keys for GMap. I guess we should. Regards -- Adrian Hey From gwern0 at gmail.com Thu Jun 19 12:06:46 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Thu Jun 19 12:00:13 2008 Subject: Package spam :-) In-Reply-To: <20080618201125.GG24043@scytale.galois.com> References: <4858F398.20708@iee.org> <20080618201125.GG24043@scytale.galois.com> Message-ID: <20080619160646.GA21711@craft> On 2008.06.18 13:11:25 -0700, Don Stewart scribbled 1.4K characters: > As author Adrian, you can ask to have them removed. > > Gwern: do not upload other people's packages, if they're active! It is > impolite, and leads to far too much broken code. > > In particular, doing random forks of existing packages with their own > matainers *is not helpful* -- it just leads to broken, unmaintained code. > > Adrian, as these packages simply fork needlessly, or aren't of suitable > quality, I think you can ask Ross to remove them. ... > > -- Don I'd like to note that these were not 'random forks'. JPB, the collections maintainer, apparently he split them up last year, listing himself and Hey as maintainers of various packages. All I did was fix up the usual Cabal breakage and re-upload when he accepted my patches; otherwise they are as they were. -- gwern Summercon Pine t Crowell SCUD Exon 26 SBS Secure CIA -------------- 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/20080619/225102a1/attachment.bin From haskell at list.mightyreason.com Thu Jun 19 13:06:33 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Thu Jun 19 12:58:30 2008 Subject: Broken packages on hackage In-Reply-To: <4858AE61.3030902@list.mightyreason.com> References: <20080617232606.GN19304@scytale.galois.com> <4858AE61.3030902@list.mightyreason.com> Message-ID: <485A9219.3070902@list.mightyreason.com> Chris Kuklewicz wrote: > Don Stewart wrote: >> Just did a full run over hackage, building packages with ghc 6.8.2, >> bytestring 0.9.0.1 and cabal 1.4.1.. >> >> The following could be marked broken, if we could do that. >> >> Depends on something hidden: >> regex-dfa I consider this unsupported >> regex-parsec I consider this unsupported >> regex-pcre Works for me >> regex-tdfa Hackage already has a http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regex-tdfa-0.92-ghc-68-build-fix version of this package, which I suspect works. From droundy at darcs.net Thu Jun 19 13:39:29 2008 From: droundy at darcs.net (David Roundy) Date: Thu Jun 19 13:31:20 2008 Subject: Proposal: overhaul System.Process In-Reply-To: <20080619035758.GC11561@lucky.cynic.net> References: <480E6478.5040209@gmail.com> <17463614.post@talk.nabble.com> <1211758855.5824.570.camel@localhost> <17993548.post@talk.nabble.com> <20080619035758.GC11561@lucky.cynic.net> Message-ID: <20080619173927.GX32397@darcs.net> On Thu, Jun 19, 2008 at 12:57:58PM +0900, Curt Sampson wrote: > On 2008-06-18 15:37 -0700 (Wed), Frederik Eaton wrote: > > > My only concerns are that deprecating the old interfaces seems like a > > declaration of intent to eventually remove them. > > Just as one opinion, I prefer that old interfaces get removed. I have > no problem updating code to deal with this kind of stuff, and the cost > of that is easily paid off (for me) in the benefits I get from having > simple interfaces available. I found Java's libraries quite trying due > to the amount of cruft one was always wading through. Here's an idea: perhaps deprecated functions should be exported in a new module System.Process.Deprecated? Then they could be left in that module after they've been removed from System.Process, if they ever are removed. That would allow for a slightly easier transition. I don't like the idea of forcing users of System.Process who are happy with the existing interface (e.g. darcs... which is not quite happy with it, but can get by) to either use #ifdefs (or something like that) or to limit their code to specific versions of ghc. Not too long ago, I was bothered by being unable to compile darcs on a system with only ghc 6.2. True, I could have compiled and installed a new ghc, but I didn't want to do so just to get a newer version of darcs, so I'm still using darcs 1.0.2 on that system (which I don't maintain, and is still running debian sarge). Of course, moving the functions to a new module doesn't help *that* much, but it's easier to change the name of a module imported than to maintain two entirely different codebases for calling external programs (which is rather a fragile part of almost any code that will be using System.Process). Perhaps a better option would be to keep the old interface indefinitely, but update haddock to allow deprecated interfaces to be documented only on a separate page. Then you needn't break anyone's code, and new users would also not need to wade through a half dozen ancient functions with weird naming conventions. David From dons at galois.com Thu Jun 19 13:40:05 2008 From: dons at galois.com (Don Stewart) Date: Thu Jun 19 13:31:56 2008 Subject: [richardg@richardg.name: HUnit] Message-ID: <20080619174005.GC27331@scytale.galois.com> Forwarded from glasgow-haskell ----- Forwarded message from Richard Giraud ----- Date: Wed, 18 Jun 2008 23:04:01 -0600 From: Richard Giraud To: glasgow-haskell-users@haskell.org Subject: HUnit I've converted the literate Haskell documentation and filled in the gaps for HUnit. I've posted the darcs repository with the changes and the new documentation at http://richardg.name/ Please email me with any feedback and/or patches that you might have. In a bit, I'll submit the patches for inclusion into the GHC repository. Richard G. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ----- End forwarded message ----- From dons at galois.com Thu Jun 19 13:41:58 2008 From: dons at galois.com (Don Stewart) Date: Thu Jun 19 13:34:05 2008 Subject: Package spam :-) In-Reply-To: <20080619160646.GA21711@craft> References: <4858F398.20708@iee.org> <20080618201125.GG24043@scytale.galois.com> <20080619160646.GA21711@craft> Message-ID: <20080619174158.GA27366@scytale.galois.com> gwern0: > On 2008.06.18 13:11:25 -0700, Don Stewart scribbled 1.4K characters: > > As author Adrian, you can ask to have them removed. > > > > Gwern: do not upload other people's packages, if they're active! It is > > impolite, and leads to far too much broken code. > > > > In particular, doing random forks of existing packages with their own > > matainers *is not helpful* -- it just leads to broken, unmaintained code. > > > > Adrian, as these packages simply fork needlessly, or aren't of suitable > > quality, I think you can ask Ross to remove them. > ... > > > > -- Don > > I'd like to note that these were not 'random forks'. JPB, the > collections maintainer, apparently he split them up last year, listing > himself and Hey as maintainers of various packages. All I did was fix > up the usual Cabal breakage and re-upload when he accepted my patches; > otherwise they are as they were. Why not let the package maintainer upload? Especially since we've now duplicate avltree and cordering libraries, this seems to not have been a useful move. -- Don From duncan.coutts at worc.ox.ac.uk Thu Jun 19 15:15:27 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jun 19 15:02:39 2008 Subject: Cabal-1.4: library-dirs and include-dirs missing from package description after install In-Reply-To: <79d7c4980806170350w17857325ve090338df482f5d5@mail.gmail.com> References: <79d7c4980806160615rdf5c0f6wa6a189128b3bf5ff@mail.gmail.com> <1213642735.15010.651.camel@localhost> <79d7c4980806170350w17857325ve090338df482f5d5@mail.gmail.com> Message-ID: <1213902927.15010.900.camel@localhost> On Tue, 2008-06-17 at 11:50 +0100, Alistair Bayley wrote: > I've pushed the current Setup and .cabal to our repo. You can say: > darcs get http://darcs.haskell.org/takusen > > Then do this: > ghc --make Setup > setup configure -fodbc -fsqlite -fpostgres > (note that you need to have these backends on your path; perhaps > just -fodbc -fsqlite for you?) > setup register --gen-pkg-config > > I've just done this. Takusen.buildinfo contains: > > extra-libraries: odbc32 pq sqlite3 > extra-lib-dirs: "C:\\Program Files\\sqlite3\\" > C:/PROGRA~1/POSTGR~1/8.1/lib > includes: > install-includes: > include-dirs: "C:\\Program Files\\sqlite3\\" > C:/PROGRA~1/POSTGR~1/8.1/include > C:/PROGRA~1/POSTGR~1/8.1/include/server Ok, so the issue is that only the autoconfUserHooks looks for .buildinfo files. The assumption was that configure scripts would want to write a .buildinfo file while Setup.hs scripts can do it directly without needing to go via any file. However the UserHooks api doesn't make it all that convenient to return an adjusted BuildInfo record. There is: preConf :: Args -> ConfigFlags -> IO HookedBuildInfo, which looks like what you want, but because it runs before configure it doesn't give you access to all the stuff that the configure step does (all the stuff in LocalBuildInfo). So probably the easiest thing to do is to use the autoconfUserHooks anyway and make sure you override postConf otherwise it'll try to find a ./configure script to run. The reason I couldn't reproduce it before of course is that I was making assumptions about what you were doing and using autoconfUserHooks :-) Duncan From duncan.coutts at worc.ox.ac.uk Thu Jun 19 18:44:27 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jun 19 18:31:32 2008 Subject: Broken packages on hackage In-Reply-To: <485A9219.3070902@list.mightyreason.com> References: <20080617232606.GN19304@scytale.galois.com> <4858AE61.3030902@list.mightyreason.com> <485A9219.3070902@list.mightyreason.com> Message-ID: <1213915467.15010.941.camel@localhost> On Thu, 2008-06-19 at 18:06 +0100, Chris Kuklewicz wrote: > Chris Kuklewicz wrote: > > Don Stewart wrote: > >> Just did a full run over hackage, building packages with ghc 6.8.2, > >> bytestring 0.9.0.1 and cabal 1.4.1.. > >> > >> The following could be marked broken, if we could do that. > >> > >> Depends on something hidden: > >> regex-dfa > I consider this unsupported > > >> regex-parsec > I consider this unsupported We need to get that feature on hackage to let us mark packages obsolete or superseded. http://hackage.haskell.org/trac/hackage/ticket/261 > >> regex-pcre > Works for me > > >> regex-tdfa > > Hackage already has a > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regex-tdfa-0.92-ghc-68-build-fix > version of this package, which I suspect works. Just to note: Cabal/cabal-install does not deal very well with packages that have tags in their versions. We've no idea how they sort compared to other tags or no tags. We're going in the direction of disallowing tags in versions completely. Duncan From frederik at ofb.net Thu Jun 19 19:20:52 2008 From: frederik at ofb.net (Frederik Eaton) Date: Thu Jun 19 19:12:40 2008 Subject: Proposal: overhaul System.Process In-Reply-To: <20080619015555.GV32397@darcs.net> References: <480E6478.5040209@gmail.com> <17463614.post@talk.nabble.com> <1211758855.5824.570.camel@localhost> <17993548.post@talk.nabble.com> <20080618224648.GU32397@darcs.net> <17994178.post@talk.nabble.com> <20080619015555.GV32397@darcs.net> Message-ID: <18020140.post@talk.nabble.com> David Roundy-2 wrote: > > On Wed, Jun 18, 2008 at 04:22:24PM -0700, Frederik Eaton wrote: >> David Roundy-2 wrote: >> > No, createProcess is more low-level than the previous interface, which >> > is why it can't be implemented using the previous interfaces, but >> > rather they can be implemented using createProcess. Which is why they >> > can be deprecated, although I'd hope they won't be removed for at >> > least a couple more ghc releases after createProcess is introduced. >> >> In what way is 'createProcess' more low-level than the previous >> interfaces? > > The easiest sense in which it's more low-level is that the previous > two commands runProcess and runInteractiveProcess can both be > implemented using createProcess, but not the other way around. > > New API: (a subset thereof, actually) > > createProcess :: CreateProcess > -> IO (Maybe Handle, Maybe Handle, Maybe Handle, > ProcessHandle) > > data CreateProcess = CreateProcess { > cmdspec :: CmdSpec > cwd :: (Maybe FilePath) > env :: (Maybe [(String, String)]) > std_in :: StdStream > std_out :: StdStream > std_err :: StdStream > close_fds :: Bool > } > > Old API: > > runProcess :: FilePath -> [String] -> Maybe FilePath > -> Maybe [(String, String)] > -> Maybe Handle -> Maybe Handle -> Maybe Handle > -> IO ProcessHandle > > runInteractiveProcess :: FilePath -> [String] > -> Maybe FilePath -> Maybe [(String, String)] > -> IO (Handle, Handle, Handle, ProcessHandle) > > In the old API, you are required to either use preexisting handles for > each of stdin/stdout/stderr (possibly allowing the child process to > inherit some or all of them), *or* create new pipes for all three. > > You might consider trying to implement runInteractiveProcess using > runProcess (you certainly can't do the opposite) by setting up pipes > and passing them to runProcess, but there's no portable function that > can be used to do this, so you'd be out of luck. You'd be stuck doing > what darcs has long done: write to temporary files on disk, which is > totally braindead. > > createProcess is (so far as I can tell) the lowest-level *portable* > Haskell API for spawning processes that has yet been proposed, in the > sense that there are no other proposed functions that could be used to > implement createProcess, and no other proposed functions that cannot > be implemented using createProcess. > It sounds like we are confusing "low-level" with "powerful". I don't know enough about portability and the constraints imposed by portability to comment on what else could be done, but the fact that we keep changing interfaces for process execution suggests to me that the existing interfaces have not been low-level enough. For instance, why can't we create a pipe independently of a process? What about creating pipes to file descriptors other than standard input/output/error? If we had good Haskell interfaces to OS-level primitives, as John Meacham suggested, then we could build something that tries to be a "greatest common denominator" on top of these. I am skeptical that the result would look very much like 'createProcess', for instance doesn't Windows have a concept of file descriptors other than standard input/output/error? I suppose that I can always use System.Posix.Process, though, and hope that it doesn't change too much... Frederik -- View this message in context: http://www.nabble.com/Proposal%3A-overhaul-System.Process-tp16844161p18020140.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. From frederik at ofb.net Thu Jun 19 19:35:19 2008 From: frederik at ofb.net (Frederik Eaton) Date: Thu Jun 19 19:27:06 2008 Subject: Proposal: overhaul System.Process In-Reply-To: <20080619173927.GX32397@darcs.net> References: <480E6478.5040209@gmail.com> <17463614.post@talk.nabble.com> <1211758855.5824.570.camel@localhost> <17993548.post@talk.nabble.com> <20080619035758.GC11561@lucky.cynic.net> <20080619173927.GX32397@darcs.net> Message-ID: <18020264.post@talk.nabble.com> David Roundy-2 wrote: > > On Thu, Jun 19, 2008 at 12:57:58PM +0900, Curt Sampson wrote: >> On 2008-06-18 15:37 -0700 (Wed), Frederik Eaton wrote: >> >> > My only concerns are that deprecating the old interfaces seems like a >> > declaration of intent to eventually remove them. >> >> Just as one opinion, I prefer that old interfaces get removed. I have >> no problem updating code to deal with this kind of stuff, and the cost >> of that is easily paid off (for me) in the benefits I get from having >> simple interfaces available. I found Java's libraries quite trying due >> to the amount of cruft one was always wading through. > > Here's an idea: perhaps deprecated functions should be exported in a > new module System.Process.Deprecated? Then they could be left in that > module after they've been removed from System.Process, if they ever > are removed. That would allow for a slightly easier transition. I > don't like the idea of forcing users of System.Process who are happy > with the existing interface (e.g. darcs... which is not quite happy > with it, but can get by) to either use #ifdefs (or something like > that) or to limit their code to specific versions of ghc. Not too > long ago, I was bothered by being unable to compile darcs on a system > with only ghc 6.2. True, I could have compiled and installed a new > ghc, but I didn't want to do so just to get a newer version of darcs, > so I'm still using darcs 1.0.2 on that system (which I don't maintain, > and is still running debian sarge). > > Of course, moving the functions to a new module doesn't help *that* > much, but it's easier to change the name of a module imported than to > maintain two entirely different codebases for calling external > programs (which is rather a fragile part of almost any code that will > be using System.Process). > > Perhaps a better option would be to keep the old interface > indefinitely, but update haddock to allow deprecated interfaces to be > documented only on a separate page. Then you needn't break anyone's > code, and new users would also not need to wade through a half dozen > ancient functions with weird naming conventions. > What's wrong with Simon Marlow's proposed haddock documentation? http://darcs.haskell.org/~simonmar/process/System-Process.html It puts the new stuff at the top. The old stuff goes under "Specific variants of createProcess". The "Synopsis" section doesn't make this separation very clear, and that could be improved, but otherwise it seems good enough. Under 'runProcess' it says "Note: consider using the more general createProcess instead of runProcess.". Sure, Haddock could be updated to put certain interfaces on a separate page or under a collapsed tab. Certainly it would be better to do that than to remove the interfaces (or even put them under a different module name, which still leads to compatibility headaches), but who knows when somebody will have time to make such changes to Haddock. If people want to have a System.Process package with only createProcess and no runProcess, then I still think that the best way to do that would be to make a new package with a new name. That seems preferable to removing names from an existing package, because it doesn't require people to change their code. Frederik -- View this message in context: http://www.nabble.com/Proposal%3A-overhaul-System.Process-tp16844161p18020264.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. From droundy at darcs.net Thu Jun 19 20:00:25 2008 From: droundy at darcs.net (David Roundy) Date: Thu Jun 19 19:52:14 2008 Subject: Proposal: overhaul System.Process In-Reply-To: <18020140.post@talk.nabble.com> References: <480E6478.5040209@gmail.com> <17463614.post@talk.nabble.com> <1211758855.5824.570.camel@localhost> <17993548.post@talk.nabble.com> <20080618224648.GU32397@darcs.net> <17994178.post@talk.nabble.com> <20080619015555.GV32397@darcs.net> <18020140.post@talk.nabble.com> Message-ID: <20080620000025.GZ32397@darcs.net> On Thu, Jun 19, 2008 at 04:20:52PM -0700, Frederik Eaton wrote: > David Roundy-2 wrote: > > createProcess is (so far as I can tell) the lowest-level *portable* > > Haskell API for spawning processes that has yet been proposed, in the > > sense that there are no other proposed functions that could be used to > > implement createProcess, and no other proposed functions that cannot > > be implemented using createProcess. > > It sounds like we are confusing "low-level" with "powerful". I don't know > enough about portability and the constraints imposed by portability to > comment on what else could be done, but the fact that we keep changing > interfaces for process execution suggests to me that the existing interfaces > have not been low-level enough. For instance, why can't we create a pipe > independently of a process? What about creating pipes to file descriptors > other than standard input/output/error? If we had good Haskell interfaces to > OS-level primitives, as John Meacham suggested, then we could build > something that tries to be a "greatest common denominator" on top of these. > I am skeptical that the result would look very much like 'createProcess', > for instance doesn't Windows have a concept of file descriptors other than > standard input/output/error? I suppose that I can always use > System.Posix.Process, though, and hope that it doesn't change too much... The problem presumably is that there isn't sufficient similarity between systems to create smaller components which are themselves cross-platform that can be combined to write a function like createProcess. I don't know enough windows programming to confirm or deny whether it would be possible to create a cross-platform pipe-creation function, but I doubt it would be possible to create something with semantics sufficiently similar to posix pipes so as to be useful. There's certainly no guarantee that there exist "small" cross-platform pieces that can be used to construct a powerful process-spawning function. Perhaps Simon can enlighten us? I just did a bit of a search and came across a bit of API from microsoft: http://msdn.microsoft.com/en-us/library/ms682425(VS.85).aspx It looks vaguely similar to the posix approach: you create pipes, create backup copies of whichever of stdin/out/err you wish to change, set your stdin/out/err to the values you wish to pass to your child process, spawn the process, then you set stdin/out/err back to your saved values, and maybe close one end of the newly-created pipes (I'm not sure of this). Under posix, the order is different, which probably means that you can't break this into smaller pieces. Under posix, you fork first, and only then do you modify stdin/out/err and close one end of any pipes you might have created, and then call exec. Since the order of operations is different, we can't write a portable version of Simon's createProcess out of pretty smaller pieces. Obviously, we could write it out of functions like forkIfWeAreRunningPosix, etc, but that would be stupid. That's my half-baked analysis, based on reading a couple of web pages... David From dan.doel at gmail.com Thu Jun 19 21:24:37 2008 From: dan.doel at gmail.com (Dan Doel) Date: Thu Jun 19 21:16:25 2008 Subject: Package spam :-) In-Reply-To: <20080619160646.GA21711@craft> References: <4858F398.20708@iee.org> <20080618201125.GG24043@scytale.galois.com> <20080619160646.GA21711@craft> Message-ID: <200806192124.37772.dan.doel@gmail.com> On Thursday 19 June 2008, Gwern Branwen wrote: > I'd like to note that these were not 'random forks'. JPB, the collections > maintainer, apparently he split them up last year, listing himself and Hey > as maintainers of various packages. All I did was fix up the usual Cabal > breakage and re-upload when he accepted my patches; otherwise they are as > they were. For what it's worth, I'm the one who suggested to Gwern that he update the cabal stuff for collections. Someone had remarked that there was no good way to make use of various collection types in the standard libraries, and I knew that the collections package on hackage took steps toward rectifying that. But, it didn't build on 6.8, due to what looked like a split-base issue. I knew Gwern had experience fixing up cabal-related stuff, so I told him he might want to try getting them fixed. Looking at my IRC logs, I see that some of the split packages mentioned already existed on hackage at the time. I noted that COrdering and Data.Tree.AVL were. I'm not sure about the rest. Now the original collections package (which was building fine on 6.6) seems to be gone from hackage, even though it had been on there for quite some time (over a year, at a guess). -- Dan From bernardy at chalmers.se Fri Jun 20 04:01:29 2008 From: bernardy at chalmers.se (Jean-Philippe Bernardy) Date: Fri Jun 20 03:53:14 2008 Subject: Package spam :-) In-Reply-To: <200806192124.37772.dan.doel@gmail.com> References: <4858F398.20708@iee.org> <20080618201125.GG24043@scytale.galois.com> <20080619160646.GA21711@craft> <200806192124.37772.dan.doel@gmail.com> Message-ID: <953e0d250806200101l643878ceq480a22c5906ce8c@mail.gmail.com> > For what it's worth, I'm the one who suggested to Gwern that he update the > cabal stuff for collections. Someone had remarked that there was no good way > to make use of various collection types in the standard libraries, and I knew > that the collections package on hackage took steps toward rectifying that. > But, it didn't build on 6.8, due to what looked like a split-base issue. I > knew Gwern had experience fixing up cabal-related stuff, so I told him he > might want to try getting them fixed. FWIW (again) : * I think collections-api is a good base to give a uniform API to a lot of data structures on hackage. - It uses FD style though, so one might want to adapt it to AT soon. (I tried with GHC 6.8 but support was too buggy). - In particular, it can be useful to write a polymorphic testing and benchmarking framework. * I have no time to maintain collections. As Adrian said before, this is an unpaid, thankless job, so my motivation went downhill since I started the project. * I did not remember that Adrian had reclaimed some parts and uploaded them separately. Corresponding code in the collections repo should be removed and the rest adapted to use Adrian's version. * Hence, I gave a "don't care" signal to Gwern when he proposed uploading to hackage. We already discussed this before, but that repository can be considered orphaned. I'll give pointers to anybody interested in adopting it. Cheers, JP. From ross at soi.city.ac.uk Fri Jun 20 05:06:26 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Fri Jun 20 04:58:15 2008 Subject: Package spam :-) In-Reply-To: <953e0d250806200101l643878ceq480a22c5906ce8c@mail.gmail.com> References: <4858F398.20708@iee.org> <20080618201125.GG24043@scytale.galois.com> <20080619160646.GA21711@craft> <200806192124.37772.dan.doel@gmail.com> <953e0d250806200101l643878ceq480a22c5906ce8c@mail.gmail.com> Message-ID: <20080620090626.GA2361@soi.city.ac.uk> On Fri, Jun 20, 2008 at 10:01:29AM +0200, Jean-Philippe Bernardy wrote: > We already discussed this before, but that repository can be > considered orphaned. I'll give pointers to anybody interested in > adopting it. Thanks for the clarification, Jean-Philippe. On the broader issue, personally I'd prefer not to have non-maintained packages on hackageDB (because their presence lowers people's expectations of the whole collection) but others disagree on that point. If we must have them, they ought not to be marked as maintained. It's not fair on users, or on the person named as maintainer. From alistair at abayley.org Fri Jun 20 05:19:43 2008 From: alistair at abayley.org (Alistair Bayley) Date: Fri Jun 20 05:11:31 2008 Subject: Cabal-1.4: library-dirs and include-dirs missing from package description after install In-Reply-To: <1213902927.15010.900.camel@localhost> References: <79d7c4980806160615rdf5c0f6wa6a189128b3bf5ff@mail.gmail.com> <1213642735.15010.651.camel@localhost> <79d7c4980806170350w17857325ve090338df482f5d5@mail.gmail.com> <1213902927.15010.900.camel@localhost> Message-ID: <79d7c4980806200219i647d16albeb5fd6b39b474c4@mail.gmail.com> 2008/6/19 Duncan Coutts : > > Ok, so the issue is that only the autoconfUserHooks looks for .buildinfo > files. The assumption was that configure scripts would want to write > a .buildinfo file while Setup.hs scripts can do it directly without > needing to go via any file. > > So probably the easiest thing to do is to use the autoconfUserHooks > anyway and make sure you override postConf otherwise it'll try to find > a ./configure script to run. > > The reason I couldn't reproduce it before of course is that I was making > assumptions about what you were doing and using autoconfUserHooks :-) Well, partly my fault. I was using defaultUserHooks, but this is now marked as deprecated, so I changed it to simpleUserHooks. Make a change, something breaks, is there a connection? :-) We were always overriding the postConf hook, so using autoconfUserHooks as a defaultUserHooks replacement seems to work. Thanks, Alistair From duncan.coutts at worc.ox.ac.uk Fri Jun 20 05:42:34 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Jun 20 05:29:33 2008 Subject: Cabal-1.4: library-dirs and include-dirs missing from package description after install In-Reply-To: <79d7c4980806200219i647d16albeb5fd6b39b474c4@mail.gmail.com> References: <79d7c4980806160615rdf5c0f6wa6a189128b3bf5ff@mail.gmail.com> <1213642735.15010.651.camel@localhost> <79d7c4980806170350w17857325ve090338df482f5d5@mail.gmail.com> <1213902927.15010.900.camel@localhost> <79d7c4980806200219i647d16albeb5fd6b39b474c4@mail.gmail.com> Message-ID: <1213954954.15010.963.camel@localhost> On Fri, 2008-06-20 at 10:19 +0100, Alistair Bayley wrote: > 2008/6/19 Duncan Coutts : > > > > Ok, so the issue is that only the autoconfUserHooks looks for .buildinfo > > files. The assumption was that configure scripts would want to write > > a .buildinfo file while Setup.hs scripts can do it directly without > > needing to go via any file. > > > > So probably the easiest thing to do is to use the autoconfUserHooks > > anyway and make sure you override postConf otherwise it'll try to find > > a ./configure script to run. > > > > The reason I couldn't reproduce it before of course is that I was making > > assumptions about what you were doing and using autoconfUserHooks :-) > > > Well, partly my fault. I was using defaultUserHooks, but this is now > marked as deprecated, so I changed it to simpleUserHooks. Make a > change, something breaks, is there a connection? :-) Yep. defaultUserHooks was completely misleading as it was not the default. (!!?!) Yes, you might reasonably have expected that defaultMain = defaultMainWithHooks defaultUserHooks but no. defaultUserHooks was actually really autoconfUserHooks except that if a ./configure script was not found it did not complain. This caused confusion all round (especially for packages that really did need a ./configure but where ./configure was not executable eg because it was from a darcs repo or because it had to be generated with autoconf). > We were always overriding the postConf hook, so using > autoconfUserHooks as a defaultUserHooks replacement seems to work. Ok. Duncan From ahey at iee.org Fri Jun 20 06:51:40 2008 From: ahey at iee.org (Adrian Hey) Date: Fri Jun 20 06:43:33 2008 Subject: Generic tries (long) In-Reply-To: References: <10ed1a750806161228t12b974dx18395853e2b9e5f2@mail.gmail.com> <10ed1a750806181516o1e46cd7fp7d288631f20f9bd4@mail.gmail.com> Message-ID: <485B8BBC.9030303@iee.org> Hello apfelmus, Thanks for taking the time to look at this. As what Jamie has posted is largely based on my own initial efforts I can offer some insight about what's going on here and why the class API looks like it does. The first thing to note is that what Jamie has posted is the proposed class methods *only*. It's not the complete user level map API. There's also a whole lot of more convenient and sensible looking functions that are just regular overloaded functions. Unfortunately these are not visible in the API posted. Among them are things like this.. size :: GT map k => map a -> Int size mp = ASINT(addSize mp L(0)) (ASINT and L are a cpp macros) elemsAscending :: GT map k => map a -> [a] elemsAscending mp = foldrElemsAscending (:) mp [] assocsAscending :: GT map k => map a -> [(k,a)] assocsAscending mp = foldrAssocsAscending (\k a assocs -> (k,a):assocs) mp [] keysAscending :: GT map k => map a -> [k] keysAscending mp = foldrKeysAscending (:) mp [] The second thing to note is that the class API has been designed with the *implementation* of generalised tries in mind. It's not necessary that any instance is actually implemented as any kind of trie, but it is necessary that the resulting API contains what's needed to enable its use in other instances that are based on generalised tries. So the actual class methods chosen are designed to be convenience for generalised trie implementation, not typical map users. The types are chosen to reflect how they will likely be used in other generalised trie implementations and the functionality provided is what it seems is actually needed to do this efficiently. What the class API contains has kind of evolved empirically with stuff being added as and when it was discovered it was needed (by implementing a few common instancance by hand). Here's my thoughtS about your specific observations.. apfelmus wrote: > 1) Some terminology seems queer to me. In particular, I don't like the > terms "assoc" and "association" in the documentation. The Data.Map > documentation uses "key/value pair" or just "key" and "value"/"element" > instead, which I think is much better. For instance: > > "Insert a new association in the map" :( > "Insert a new key and value in the map." :) > > Also, I like fromList better than fromAssocs . Well this is one of those bike shed arguments :-) I'm easy about it so if Jamie agrees with you that's fine. Use of the term "association" seems quite common. I've seen numereous uses of the term "association list", never seen anyone talk about "key/value pair list". > 2) Don't use Int# , looks like a premature optimization to me. > Furthermore, I'd change the queer addSize to simply > > size :: map a -> Int This does exist (see above), but it's not a class method. One could argue that is was unnecessary to make unboxing explicit. It's something I got into the habit of doing because it's way easier to do that than is inspecting ghc's output to make it's done it on its own (and figuring out what to do about it if it hasn't). Also, because of the nested nature generalised tries addSize is more convenient for implementors than size IMO. > 3) insert is strange. Why not use the convention in Data.Map, name it > insertWith and have > > insert :: k -> a -> map a -> map a > instead? Yes, this this should probably be added to the user API. As a choice of primitive class method, the current form seems more appropriate (though perhaps not it's name). All the common user level variants can easily be implemented with this primitive. > Similar for union . Actually I don't like Data.Maps union much. It would be deprecated if I ruled the world. I think users should be always be made to specify how overlapping values are to be combined (or discarded or whatever). So the name union is now free we don't need to qualify the function that is explicit about this using a "With" suffix. > 4) Most functions, in particular the ..Maybe variants have fixed > default definitions. I wouldn't include them in the class. How about a > minimal class interface along the lines of > > class GMap map k | map -> k where > empty :: map a > null :: map a -> Bool > > lookup :: k -> map a -> Maybe a > alter :: (Maybe a -> Maybe a) -> k -> map a -> map a > merge :: (k -> Maybe a -> Maybe b -> Maybe c) -> map a -> map b > -> map c > > fromList :: [(k,a)] -> map a > toList :: map a -> [(k,a)] > > instance Functor map where ... > > and implementing the various variants as normal polymorphic functions? Like > > insert k a = alter (const $ Just a) k > singleton k a = insert k a empty > > IMHO, having a few "flag" functions like > > difference :: k -> Maybe a -> Maybe b -> Maybe b > union :: k -> Maybe a -> Maybe a -> Maybe a > intersect :: k -> Maybe a -> Maybe a -> Maybe a > > that can be plugged into merge is much nicer than having to > remember/lookup all the ..Maybe and whatnot'' variants. I've never been very keen on alter myself (on efficiency grounds) and was wondering whether of not to include it. If the "altering" results in an unchanged map it would be nice to just return the unchanged map (rather than duplicate all nodes on the search path). There are other possible alternatives to alter that are more efficient in this respect. The merge function looks like an interesting idea, but it's not clear to me that it can always (or ever even :-) be implemented as efficiently as the more specialised versions. Maybe as and experiment we could implement it and if it turns out that union,intersection etc can be implemeted using it with liitle or no extra cost then we could put them in the convinience API instead (not as class methods). > 5) I think the following functions are queer > > lookupCont f k m = lookup k m >>= f Or perhaps.. lookup = lookupCont Just Yes, there's probably unwanted duplication in the class methods there. My vote would be to keep lookupCont and a class method and have lookup as regular overloaded function. > pair k1 k2 = if k1 == k2 then Nothing else > Just $ \a1 a2 -> insert k1 a1 (insert k2 a2 empty) > > What use is pair ? I'd definitively put them outside the class if not > remove them entirely. Again, pair is one of those things that a typical Map user wouldn't use, but is definitely needed to implement an efficient trie for Lists and probably product types in general. The reason for it's existance is that singleton maps need special treatment (you want to avoid making long chains of them). Unfortunately the above definition is inefficient. You've already done most of the work requred to evaluate pair in the first equality test. This would all have to be repeated in the second insertion. Have a look at the ListGT module to see how pair is defined and used for the gory details. > 6) status is an interesting idea with a meaningless name. Don't you > have a name that is more to the point, that expresses the nub (pun > intended) of what status does? If you're suggesting it should be called nub, that seems confusing considering that name is already used in Data.List to mean something quite different. Perhaps you can suggest some other name? > 7) I'm overwhelmed by the many foldr...Asc/Descending functions. They > all can be expressed in terms of toListAsc and toListDesc and I > don't think that "marginally faster" is a reason not to do so. ..or vice-versa, but without the need for list deforestation to get the same efficiency. Also I think we need to distinguish between the variants that require key reconstruction from those that don't (keys generally aren't stored in a trie). > I'd throw away the from...L functions, too. The L versions can improve performance in some map implementations where length is needed and is already known as by product of other stuff that's going on. In such cases it seems to make sense to pass it as an argument rather than incur the cost of evaluating it again from scratch. Anway, I don't think we should get to worried about the precise details of class methods right now. I think the main concern should be getting the class hierarchy right, I'm not sure that it at present. e.g. There may be specialised representations that support lookup very efficiently but not much else. Should we have a separate class for them? Should we have separate classes for implementations that store keys (hence no key reconstruction cost) and those that must reconstruct keys? Then there's the ordering can of worms too. This is the sort of thing that really needs to be got right from the start IMHO. Regards -- Adrian Hey From igloo at earth.li Fri Jun 20 10:00:56 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Jun 20 09:52:43 2008 Subject: Generic tries (long) In-Reply-To: <485B8BBC.9030303@iee.org> References: <10ed1a750806161228t12b974dx18395853e2b9e5f2@mail.gmail.com> <10ed1a750806181516o1e46cd7fp7d288631f20f9bd4@mail.gmail.com> <485B8BBC.9030303@iee.org> Message-ID: <20080620140056.GA14809@matrix.chaos.earth.li> On Fri, Jun 20, 2008 at 11:51:40AM +0100, Adrian Hey wrote: > > >2) Don't use Int# , looks like a premature optimization to me. > >Furthermore, I'd change the queer addSize to simply > > > > size :: map a -> Int > > This does exist (see above), but it's not a class method. One could > argue that is was unnecessary to make unboxing explicit. It's something > I got into the habit of doing because it's way easier to do that than > is inspecting ghc's output to make it's done it on its own (and figuring > out what to do about it if it hasn't). Also, because of the nested > nature generalised tries addSize is more convenient for implementors > than size IMO. I agree that using Int# is a bad idea. It makes the package unportable, and it forces all the packages that implement the class to write code using Int#. Thanks Ian From apa3a at yahoo.com Fri Jun 20 10:02:21 2008 From: apa3a at yahoo.com (Andriy Palamarchuk) Date: Fri Jun 20 09:54:05 2008 Subject: [richardg@richardg.name: HUnit] In-Reply-To: <20080619174005.GC27331@scytale.galois.com> Message-ID: <434277.36182.qm@web56708.mail.re3.yahoo.com> Richard, thank you for the submission. Here is the page describing how to submit changes to the library: http://haskell.org/haskellwiki/Library_submissions I like the idea of converting HUnit to non-literal style and making its comments available as haddoc documentation. People will finally find information about HUnit in the first place they look for it ;-) This will also insure the information is up-to-date. I have not looked at these changes, but in September last year I reviewed a similar patch by Leif Frenzel: http://hackage.haskell.org/trac/ghc/ticket/1632 At that time I recommended to add simple examples to the haddoc documentation how to use HUnit. That patch is not committed yet, probably because the suggested changes have not been implemented. Richard, Leif, wonder if you can coordinate the efforts to finish the patch. It would be great if the patch was finally committed and we would stop effort duplication. Thanks, Andriy --- On Thu, 6/19/08, Don Stewart wrote: > From: Don Stewart > Subject: [richardg@richardg.name: HUnit] > To: libraries@haskell.org > Date: Thursday, June 19, 2008, 1:40 PM > Forwarded from glasgow-haskell > ----- Forwarded message from Richard Giraud > ----- > > Date: Wed, 18 Jun 2008 23:04:01 -0600 > From: Richard Giraud > To: glasgow-haskell-users@haskell.org > Subject: HUnit > > I've converted the literate Haskell documentation and > filled in the gaps > for HUnit. I've posted the darcs repository with the > changes and the > new documentation at http://richardg.name/ > > Please email me with any feedback and/or patches that you > might have. > In a bit, I'll submit the patches for inclusion into > the GHC repository. > > Richard G. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > ----- End forwarded message ----- > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From ahey at iee.org Fri Jun 20 10:52:21 2008 From: ahey at iee.org (Adrian Hey) Date: Fri Jun 20 10:44:10 2008 Subject: Generic tries (long) In-Reply-To: <20080620140056.GA14809@matrix.chaos.earth.li> References: <10ed1a750806161228t12b974dx18395853e2b9e5f2@mail.gmail.com> <10ed1a750806181516o1e46cd7fp7d288631f20f9bd4@mail.gmail.com> <485B8BBC.9030303@iee.org> <20080620140056.GA14809@matrix.chaos.earth.li> Message-ID: <485BC425.50407@iee.org> Ian Lynagh wrote: > I agree that using Int# is a bad idea. It makes the package unportable, > and it forces all the packages that implement the class to write code > using Int#. As they should IMO :-) I wish this wasn't necessary, but my experience in the past tells me it is. ghc's optimisations seem too fragile to rely on for this. BTW, it's actually controlled by cpp macros, so the unboxed versions are ghc only. Unfortunately you can't tell this from the Haddock because Haddock doesn't understand cpp. But in this case it scarcely matters as it will be making use of type families which are a only going to supported by ghc anyway for the forseable future AFAIK. Regards -- Adrina Hey From ahey at iee.org Fri Jun 20 12:06:28 2008 From: ahey at iee.org (Adrian Hey) Date: Fri Jun 20 11:58:16 2008 Subject: Package spam :-) In-Reply-To: <953e0d250806200101l643878ceq480a22c5906ce8c@mail.gmail.com> References: <4858F398.20708@iee.org> <20080618201125.GG24043@scytale.galois.com> <20080619160646.GA21711@craft> <200806192124.37772.dan.doel@gmail.com> <953e0d250806200101l643878ceq480a22c5906ce8c@mail.gmail.com> Message-ID: <485BD584.1060703@iee.org> Hello Jean-Philippe Jean-Philippe Bernardy wrote: > * I have no time to maintain collections. As Adrian said before, this > is an unpaid, thankless job. I suspect Gwern Branwen feels the same way after all this :-) Maybe it would be a good idea to do a 0.4 release for the benefit of anyone interested (0.3 did have some users I believe), especially as the 0.3 release seems to have disappeared (not sure why that is). But it would be good to get the dependencies right and make sure we don't have multiple sources for "the same" code. AFAIK enumset isn't in hackage at all at the moment and it may well be useful to someone, but is what's in the collections repository the latest official version or is it being worked on elsewhere? With regard to the maintenance state of packages in hackage, I think it's fine to have dead/dormant/"looking for new owner" packages archived there, just so long as it's clear to users that this is the case (anyone who finds it useful enough to care about it's maintainance can always take over ownership if they want). As it happens I think I probably will keep maintaining the AVL stuff after all as the generalised tries package Jamie Brandon is working on will probably have a dependency on it. Regards -- Adrian Hey From dons at galois.com Fri Jun 20 14:49:17 2008 From: dons at galois.com (Don Stewart) Date: Fri Jun 20 14:41:03 2008 Subject: Package spam :-) In-Reply-To: <20080620090626.GA2361@soi.city.ac.uk> References: <4858F398.20708@iee.org> <20080618201125.GG24043@scytale.galois.com> <20080619160646.GA21711@craft> <200806192124.37772.dan.doel@gmail.com> <953e0d250806200101l643878ceq480a22c5906ce8c@mail.gmail.com> <20080620090626.GA2361@soi.city.ac.uk> Message-ID: <20080620184917.GB31722@scytale.galois.com> ross: > On Fri, Jun 20, 2008 at 10:01:29AM +0200, Jean-Philippe Bernardy wrote: > > We already discussed this before, but that repository can be > > considered orphaned. I'll give pointers to anybody interested in > > adopting it. > > Thanks for the clarification, Jean-Philippe. > > On the broader issue, personally I'd prefer not to have non-maintained > packages on hackageDB (because their presence lowers people's expectations > of the whole collection) but others disagree on that point. If we must > have them, they ought not to be marked as maintained. It's not fair on > users, or on the person named as maintainer. Perhaps if the .cabal files for orphaned packages could be marked as, say: maintainer: unmaintained or maintainer: orphaned This might alleviate some problems (a future hackage could filter unmaintained packages). Gwern, would that work for you, for these library salvaging efforts? -- Don From dons at galois.com Fri Jun 20 17:17:10 2008 From: dons at galois.com (Don Stewart) Date: Fri Jun 20 17:08:56 2008 Subject: The NetBSD Foundation Moves to a Two Clause BSD License Message-ID: <20080620211710.GG31722@scytale.galois.com> NetBSD has moved from BSD-3 to BSD-2 style licenses. A similar default for the Haskell community probably also makes sense (removing the 'endorsement' clause, which doesn't make much sense in the modern software industry). The new BSD2 license is below: ------------------------------------------------------------------------ /*- * Copyright (c) 2008 The NetBSD Foundation, Inc. * All rights reserved. * * This code is derived from software contributed to The NetBSD Foundation * by * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE * POSSIBILITY OF SUCH DAMAGE. */ From duncan.coutts at worc.ox.ac.uk Fri Jun 20 18:44:49 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Jun 20 18:31:45 2008 Subject: The NetBSD Foundation Moves to a Two Clause BSD License In-Reply-To: <20080620211710.GG31722@scytale.galois.com> References: <20080620211710.GG31722@scytale.galois.com> Message-ID: <1214001889.15010.990.camel@localhost> As I mentioned on irc, I think it's probably best to wait for other groups like debian-legal, OSI etc to ponder it. I should also point out that this now looks very much like the MIT license which is already somewhat popular amongst haskell packages on hackage, is popular in the wider free/open software community and which we've already proposed to add to Distribution.Version. It makes sense for NetBSD to go from BSD3 to BSD2 given its historical connection with the BSD license but perhaps other projects are better off with the MIT license if they do not like the 3rd clause in the BSD3 license. Duncan On Fri, 2008-06-20 at 14:17 -0700, Don Stewart wrote: > NetBSD has moved from BSD-3 to BSD-2 style licenses. > A similar default for the Haskell community probably also makes sense > (removing the 'endorsement' clause, which doesn't make much sense in the > modern software industry). > > The new BSD2 license is below: > > ------------------------------------------------------------------------ > > /*- > * Copyright (c) 2008 The NetBSD Foundation, Inc. > * All rights reserved. > * > * This code is derived from software contributed to The NetBSD Foundation > * by > * > * Redistribution and use in source and binary forms, with or without > * modification, are permitted provided that the following conditions > * are met: > * > * 1. Redistributions of source code must retain the above copyright > * notice, this list of conditions and the following disclaimer. > * > * 2. Redistributions in binary form must reproduce the above copyright > * notice, this list of conditions and the following disclaimer in the > * documentation and/or other materials provided with the distribution. > * > * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS > * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED > * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS > * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF > * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS > * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN > * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) > * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE > * POSSIBILITY OF SUCH DAMAGE. > */ > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From apfelmus at quantentunnel.de Sat Jun 21 05:09:49 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Sat Jun 21 05:01:51 2008 Subject: Generic tries (long) In-Reply-To: <485B8BBC.9030303@iee.org> References: <10ed1a750806161228t12b974dx18395853e2b9e5f2@mail.gmail.com> <10ed1a750806181516o1e46cd7fp7d288631f20f9bd4@mail.gmail.com> <485B8BBC.9030303@iee.org> Message-ID: Adrian Hey wrote: > The first thing to note is that what Jamie has posted is the proposed > class methods *only*. It's not the complete user level map API. > > The second thing to note is that the class API has been designed with > the *implementation* of generalised tries in mind. Ah ok, I thought that would be the user API already. So, the class API is for "users" who want to plug in their own generalized trie implementations? In any case, I'm all for keeping it simple and minimal, possible minor efficiency penalties notwithstanding :) >> I don't like the terms "assoc" and "association" > > Well this is one of those bike shed arguments :-) I'm easy about it so > if Jamie agrees with you that's fine. Use of the term "association" > seems quite common. I've seen numereous uses of the term "association > list", never seen anyone talk about "key/value pair list". The term "association list" seems to be atomic, i.e. it's not a list of associations. The dictionary of A&DS ( http://www.nist.gov/dads/ ) always says "key" and "value", though it doesn't mention pairs of these directly. The documentation for Data.Map uses "key/value pair" explicitly. >> alter :: (Maybe a -> Maybe a) -> k -> map a -> map a > > I've never been very keen on alter myself (on efficiency grounds) and > was wondering whether of not to include it. If the "altering" results > in an unchanged map it would be nice to just return the unchanged > map (rather than duplicate all nodes on the search path). There are > other possible alternatives to alter that are more efficient in this > respect. You mean the case when f Nothing = Nothing in alter f .. ? Hm, maybe some zipper-like extension of lookup can do the trick focus :: k -> map a -> (Maybe a, Maybe a -> map a) lookup k = fst . focus k delete k m = case focus k m of (Nothing, _) -> m (_ , g) -> g Nothing alter f k m = case focus k m of (Nothing, g) -> case f Nothing of Nothing -> m x -> g x (x , g) -> g x >> 6) status is an interesting idea with a meaningless name. Don't you >> have a name that is more to the point, that expresses the nub (pun >> intended) of what status does? > > If you're suggesting it should be called nub, that seems confusing > considering that name is already used in Data.List to mean something > quite different. Perhaps you can suggest some other name? No, it shouldn't be nub of course, just a similarly succinct yet meaningful name. Hm, maybe monkeyView in accordance with the way the monkeys count: one, two, many. :) Regards, apfelmus From apfelmus at quantentunnel.de Sat Jun 21 05:19:21 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Sat Jun 21 05:11:13 2008 Subject: Generic tries (long) In-Reply-To: <485A4EFF.2060901@iee.org> References: <10ed1a750806161228t12b974dx18395853e2b9e5f2@mail.gmail.com> <10ed1a750806181516o1e46cd7fp7d288631f20f9bd4@mail.gmail.com> <485A4EFF.2060901@iee.org> Message-ID: Adrian Hey wrote: > So I think I would really like to see a subclass that *does* guarantee > Ordering that is consistent with Ord. Why not just use class (Ord k, GMap map k) => OrderedGMap map k where instead of class GMap map k => OrderedGMap map k where compareKey :: k -> k -> Ordering for a class that indicates consistent ordering? I mean, you control the instances. For example, you can implement instance OrdGMap map k => OrdGMap map [k] because you know what the Ord instance for lists looks like. Regards, apfelmus From jcb73 at cam.ac.uk Sat Jun 21 05:47:18 2008 From: jcb73 at cam.ac.uk (Jamie Brandon) Date: Sat Jun 21 05:39:00 2008 Subject: Generic tries (long) In-Reply-To: References: <10ed1a750806161228t12b974dx18395853e2b9e5f2@mail.gmail.com> <10ed1a750806181516o1e46cd7fp7d288631f20f9bd4@mail.gmail.com> <485A4EFF.2060901@iee.org> Message-ID: <10ed1a750806210247h3474a629l58168bf2a885007b@mail.gmail.com> > Why not just use > > class (Ord k, GMap map k) => OrderedGMap map k where Most of the maps I will be implementing will respect the ordering that would be derived by GHC, regardless of the actual Ord instance. There is no way, in general, to derive a trie that respects an existing Ord instance but I still want to expose the bytewise ordering in the trie. We also already have instance Ord k => OrderedGMap OrdGT k where OrdGT use AVL trees. > The term "association list" seems to be atomic, i.e. it's not a list of associations Its not? 'Assocs' makes sense to me but I guess its best to copy the terminology in Data.Map > focus :: k -> map a -> (Maybe a, Maybe a -> map a) I like focus, alter and merge. According to quickcheck my serialisation code is now working so in a day or two I should be in a position to get some benchmarks set up. I would definitely prefer the simpler interface if it can be persuaded to run reasonably quickly. If not, I dont want to have a class definition that makes it difficult to write efficient implentations. I would rather have an ugly class and a nicer layer on top. > The first thing to note is that what Jamie has posted is the proposed > class methods *only*. It's not the complete user level map API. Sorry, I'll update the api this evening with the user facing code. I keep meaning to do it and then getting distracted by failed tests in this damn bit munging code. (In my head lists run left to right and machine words run right to left. This makes for some subtle bugs.) For now I'm going to rename insert as insertWith and put insert in the user api. Same for union, intersection etc From isaacdupree at charter.net Sat Jun 21 09:51:00 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Sat Jun 21 09:42:37 2008 Subject: Generic tries (long) In-Reply-To: <10ed1a750806210247h3474a629l58168bf2a885007b@mail.gmail.com> References: <10ed1a750806161228t12b974dx18395853e2b9e5f2@mail.gmail.com> <10ed1a750806181516o1e46cd7fp7d288631f20f9bd4@mail.gmail.com> <485A4EFF.2060901@iee.org> <10ed1a750806210247h3474a629l58168bf2a885007b@mail.gmail.com> Message-ID: <485D0744.2000304@charter.net> Jamie Brandon wrote: >> Why not just use >> >> class (Ord k, GMap map k) => OrderedGMap map k where > > Most of the maps I will be implementing will respect the ordering that > would be derived by GHC, regardless of the actual Ord instance. There > is no way, in general, to derive a trie that respects an existing Ord > instance but I still want to expose the bytewise ordering in the trie. Well, you could use a newtype for the key, when necessary. But does that suffer from 1. the risk of accidentally not using a newtype? 2. is it an inconvenience to the users of the map? I can't tell... Is it a bad idea to require an Ord context even if you don't use it? It could supply a default method... but would surely confuse people like (1) above. -Isaac From iavor.diatchki at gmail.com Sat Jun 21 11:31:01 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sat Jun 21 11:22:43 2008 Subject: Generic tries (long) In-Reply-To: <10ed1a750806161228t12b974dx18395853e2b9e5f2@mail.gmail.com> References: <10ed1a750806161228t12b974dx18395853e2b9e5f2@mail.gmail.com> Message-ID: <5ab17e790806210831m10b8addar56dce4eeb34b167@mail.gmail.com> Hi Jamie, thanks for doing this---I think that the functions in the API look good. Of course, one can always think of more :-) One that I often find useful when working with Data.Map is a function that removes a key from a map and also returns the associated value---a kind of destructive lookup. I think that the library would be better if you exposed a non-overloaded API for the map(s?) that you plan to implement. This is useful because (i) most of the type I anticipiate using a single type of map, and concrete types lead to more accurate types in type inference, (ii) it makes the API Haskell'98 and hence likely to work on most Haskell implementations out there. If you really think that the overloading is useful, then you could provide separate modules that provide the class+instances in terms of the non-overloaded API and add a cabal flag to turn these on/off. Also, as others mentioned, using Int# in an API is not great because this is a GHC internal type. If you found situatuins where GHC is not unboxing something please send a mail to the GHC team---they are usually very good at fixing these sorts of things. Adrian mentioned that you use CPP to control the use of Int# but this does not help if the Int# leaks through the API: (i) I could still have programs that work in Hugs and fail to compile in GHC (and vice versa), (ii) if I want to use your map library, I would have to compile all my programs with the CPP extensions, which is not nice. Hope this helps, -Iavor On 6/16/08, Jamie Brandon wrote: > Hi, I'm writing a library for generic tries for the Summer of Code. > The main point of this post is to get some feedback on the api but > I'll briefly explain the idea. > > The point of a trie is to exploit the recursive nature of ADTs to save > on expensive key comparisons and reduce space consumption. Hinze' > original formulation is very elegant but results in very deep > structures and is fairly inefficient. The normal trie optimisations > (concatenating singleton maps, mainly) cant be applied to the generic > version. > > I intend instead to encode ADTs as lists. This encoding can range from > a simple walk of the ADT to creating a compressed, bit packing > representation. The resulting tradeoff between encoding time and space > usage should make the design fairly flexible. This will look something > like: > > class Serial k where > > -- | Flattened form of key consists of a list of Nodes > -- Node will be Int or UArray Int for compressed implementations > type Node k > > -- | Flatten to a list of Nodes > serialise :: k -> [Node k] > > -- | Reconstruct from a list of Nodes > unserialise :: [Node k] -> k > > The api below is mostly cribbed from Adrian Hey's initial design. > Guarantees about ordering will probably vary between maps. All > ascending have descending version too. Strict versions of functions > will be written where appropriate, I've omitted them here for brevity. > Key reconstruction is likely to be expensive so it may make more sense > to seperate foldrKeys and friends into a seperate class. > > Adrian has written instance of GMap for lists, UInts and Ord types so > I can declare > instance (Serial k) => GMap (ListGMap (Node k)) k where ... etc > > I should have a spot on code.haskell.org soon, at which point I'll put > up a Haddock page with the most up to date version of the api. > > class GMap map where > > type k > > -- | The empty map. > empty :: map a > > -- | Create a map with a single association. > singleton :: k -> a -> map a > > -- | Create a map from a list of associations which /must/ be in > ascending order of keys > -- (with /no/ duplicate keys). If in doubt use one of the safer (but > slower) 'fromAssocs' functions. > fromAssocsAscending :: [(k,a)] -> map a > > -- | Return 'True' if the map contains no associations. > isEmpty :: map a -> Bool > > -- | Return 'True' if the map contains exactly one association. > isSingleton :: map a -> Bool > > -- | Return the value associated with the supplied key (if any). > lookup :: k -> map a -> Maybe a > > -- | Insert a new association in the map if there is currently no > value associated with the key. > -- If there is a value associated with the key then replace it with > the result of > -- applying the supplied function to that value. > insert :: (a -> a) -> k -> a -> map a -> map a > > -- | Delete the association for the supplied key (if any). > delete :: k -> map a -> map a > > -- | This is a combined insert\/modify\/delete operation. The argument > to the supplied function > -- is ('Just' a) if there is a value (a) associated with the supplied > key, otherwise 'Nothing'. > -- If the return value is ('Just' a'), a' becomes the new value > associated with the supplied key. > -- If the return value is 'Nothing', the association for the supplied > key (if any) is deleted. > alter :: (Maybe a -> Maybe a) -> k -> map a -> map a > > -- | Evaluate the union of two maps. If the maps contain common keys > then combine the > -- values associated with those keys using the supplied function. The > value arguments > -- to this function are supplied in the same order as the map arguments. > union :: (a -> a -> a) -> map a -> map a -> map a > > -- | Evaluate the intersection of two maps, combining common > associations using the supplied function. > intersection :: (a -> b -> c) -> map a -> map b -> map c > > -- | Evaluate the difference between two maps. For any key occuring in > the second map, > -- the corresponding association (if any) is deleted from the first map. > -- The associated values in the second map are irrelevant. > difference :: map a -> map b -> map a > > -- | Returns true if the keys in the first map are a subset of the > keys in the second map. > -- (This includes the case where the key sets are identical). Note > that this function does > -- not examine the associated values (which are irrelevant). See > 'isSubmapOf' if you > -- do want associated values examined. > isSubsetOf :: map a -> map b -> Bool > > -- | Returns true if the keys in the first map are a subset of the > keys in the second map > -- and the corresponding function always returns true when applied to > the values associated > -- with matching keys. > isSubmapOf :: (a -> b -> Bool) -> map a -> map b -> Bool > > -- | Apply the supplied function to every associated value in the map. > map :: (a -> b) -> map a -> map b > > -- | Apply the supplied function to every association in the map, and > use the result > -- as the new associated value for the corresponding key. > mapWithKey :: (k -> a -> b) -> map a -> map b > > -- | Delete associations for which the supplied predicate returns > 'False' when applied to > -- the associated value. > filter :: (a -> Bool) -> map a -> map a > > -- | Fold right over the list of elements in ascending order of keys. > -- See 'foldrElemsAscending'' for a strict version of this function. > foldrElemsAscending :: (a -> b -> b) -> map a -> b -> b > > -- | Fold right over the list of keys in ascending order. > -- See 'foldrKeysAscending'' for a strict version of this function. > foldrKeysAscending :: (k -> b -> b) -> map a -> b -> b > > -- | Fold right over the list of associations in ascending order of keys. > -- See 'foldrAssocsAscending'' for a strict version of this function. > foldrAssocsAscending :: (k -> a -> b -> b) -> map a -> b -> b > > -- | Fold over elements in un-specified order using /unboxed/ Int > accumulator (with GHC). > -- Defaults to boxed Int for other Haskells. Typically used for > counting functions. > -- Implementations are free to traverse the map in any order. > -- The folded function is always applied strictly. > foldElemsUINT :: (a -> UINT -> UINT) -> map a -> UINT -> UINT > > In addition there a few functions which are useful for groups of maps > or nested maps. > > -- | Add the number of associations in a map to the supplied /unboxed/ > Int (with GHC). > -- Defaults to boxed Int for other Haskells. > addSize :: map a -> UINT -> UINT > > -- | Find the value associated with the supplied key (if any) and > return the result > -- of applying the supplied continuation function to that value. > Useful for nested lookup. > lookupCont :: (a -> Maybe b) -> k -> map a -> Maybe b > > -- | Reject empty maps (return Nothing). > nonEmpty :: map a -> Maybe (map a) > > The following functions are useful internally as most of the maps are > defined in terms of simpler maps. Also see this thread on the need for > unionMaybe. > > -- | Similar to 'insert', but the association is deleted if the > supplied function returns 'Nothing'. > -- (The supplied function is always applied strictly.) > insertMaybe :: (a -> Maybe a) -> k -> a -> map a -> map a > > -- | Find the value associated with the supplied key (if any) and > apply the supplied function > -- to that value. Delete the association if the result is 'Nothing'. > Replace the old value with > -- the new value if the result is ('Just' something). > -- (The supplied function is always applied strictly.) > deleteMaybe :: (a -> Maybe a) -> k -> map a -> map a > > -- | Evaluate the union of two maps, but delete combined associations > from the result map > -- if the combining function returns 'Nothing'. > -- (The combining function is always applied strictly.) > unionMaybe :: (a -> a -> Maybe a) -> map a -> map a -> map a > > -- | Evaluate the intersection of two maps, but delete combined > associations from the result map > -- if the combining function returns 'Nothing'. > -- (The combining function is always applied strictly.) > intersectionMaybe :: (a -> b -> Maybe c) -> map a -> map b -> map c > > -- | Difference with a combining function. If the combining function returns > -- @Just a@ then the corresponding association is not deleted from the > result map > -- (it is retained with @a@ as the associated value). > differenceMaybe :: (a -> b -> Maybe a) -> map a -> map b -> map a > > -- | Apply the supplied function to every associated value in the map. > -- If the result is 'Nothing' then the delete the corresponding association. > -- (The supplied function is always applied strictly.) > mapMaybe :: (a -> Maybe b) -> map a -> map b > > Thanks > > Jamie > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From gwern0 at gmail.com Sun Jun 22 01:59:23 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Sun Jun 22 01:52:16 2008 Subject: Package spam :-) In-Reply-To: <20080620184917.GB31722@scytale.galois.com> References: <4858F398.20708@iee.org> <20080618201125.GG24043@scytale.galois.com> <20080619160646.GA21711@craft> <200806192124.37772.dan.doel@gmail.com> <953e0d250806200101l643878ceq480a22c5906ce8c@mail.gmail.com> <20080620090626.GA2361@soi.city.ac.uk> <20080620184917.GB31722@scytale.galois.com> Message-ID: <20080622055923.GB30974@craft> On 2008.06.20 11:49:17 -0700, Don Stewart scribbled 0.9K characters: > ross: > > On Fri, Jun 20, 2008 at 10:01:29AM +0200, Jean-Philippe Bernardy wrote: > > > We already discussed this before, but that repository can be > > > considered orphaned. I'll give pointers to anybody interested in > > > adopting it. > > > > Thanks for the clarification, Jean-Philippe. > > > > On the broader issue, personally I'd prefer not to have non-maintained > > packages on hackageDB (because their presence lowers people's expectations > > of the whole collection) but others disagree on that point. If we must > > have them, they ought not to be marked as maintained. It's not fair on > > users, or on the person named as maintainer. > > Perhaps if the .cabal files for orphaned packages could be > marked as, say: > > maintainer: unmaintained > > or > > maintainer: orphaned > > This might alleviate some problems (a future hackage could filter > unmaintained packages). > > Gwern, would that work for you, for these library salvaging efforts? > > -- Don This *would* work for me; however, there is a reason I haven't done this or something like it before (and instead simply omitted the maintainer: field whenever I thought something was unmaintained). Fundamentally, I feel that putting something like into the free-form text field is kind of abusing it, that there should be some more structured way. As you've already pointed out, when a package is unmaintained, what is the canonical machine-readable way of saying so? We have such ways of specifying dependencies and tested-status, which is good for cabal-install. But what about maintainedness? Is it "unmaintained"? "unsupported"? "Unsupported"? "orphaned"? "Orphaned"? I can tell you just from past experience with the stability: field* that people will use all those and more if we don't give them a clear and unambiguous restriction on what can be put in - and then how will Hackage programmatically filter out unmaintained stuff? The status quo of not listing maintainer at least is programmatic - if there's a maintainer field, it's maintained by the person listed; if not, not. We could formalize this a little bit. For example, the cabal tools see an omitted maintainer field as a problem, not as a valid choice, and Hackage does nothing based on an omission. These are relatively small tweaks, though. What's the alternative? some sort of data Maintainer = None | Maintained String? But how could you then make maintainer: backwards compatible...? Add an entirely new field? (maintained: True) But then we wouldn't see it in sufficiently wide-spread use to be usable for years and years. * Which needs to be fixed for all the reasons I've listed here for maintainer:; see . -- gwern DI VIP J2 AFSPC detection STEEPLEBUSH DES chosen DDR&E RUOP -------------- 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/20080622/ba9abd05/attachment.bin From gwern0 at gmail.com Sun Jun 22 02:16:23 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Sun Jun 22 02:09:27 2008 Subject: Package spam :-) In-Reply-To: <485BD584.1060703@iee.org> References: <4858F398.20708@iee.org> <20080618201125.GG24043@scytale.galois.com> <20080619160646.GA21711@craft> <200806192124.37772.dan.doel@gmail.com> <953e0d250806200101l643878ceq480a22c5906ce8c@mail.gmail.com> <485BD584.1060703@iee.org> Message-ID: <20080622061623.GC30974@craft> On 2008.06.20 17:06:28 +0100, Adrian Hey scribbled 1.2K characters: > Hello Jean-Philippe > > Jean-Philippe Bernardy wrote: >> * I have no time to maintain collections. As Adrian said before, this >> is an unpaid, thankless job. > > I suspect Gwern Branwen feels the same way after all this :-) I'm used to it. And this sort of thing is easier than a lot of Haskell-related stuff (I would freeze in stark terror if asked to try to write something like Edward's category library), after all. And I got used to being yelled at on Wikipedia and Usenet. :) > Maybe it would be a good idea to do a 0.4 release for the benefit of > anyone interested (0.3 did have some users I believe), especially as > the 0.3 release seems to have disappeared (not sure why that is). > > But it would be good to get the dependencies right and make sure we > don't have multiple sources for "the same" code. > > AFAIK enumset isn't in hackage at all at the moment and it may well be > useful to someone, but is what's in the collections repository the > latest official version or is it being worked on elsewhere? I agree. But what do we need to do for a cleaned up release? * I think we obviously need to remove you from the various maintainer fields. You seem to be in ~half of them: gwern@craft:11210~/bin/collections-ghc6.8>grep maintainer: `find . -name "*.cabal"|grep -v _darcs` [ 2:06AM] ./collections.cabal:maintainer: jeanphilippe.bernardy (google mail) ./Data-Tree-AVL/dist/Data-Tree-AVL-0.4/Data-Tree-AVL.cabal:maintainer: http://homepages.nildram.co.uk/~ahey/em.png ./Data-Tree-AVL/Data-Tree-AVL.cabal:maintainer: http://homepages.nildram.co.uk/~ahey/em.png ./Data-COrdering/dist/Data-COrdering-0.4/Data-COrdering.cabal:maintainer: http://homepages.nildram.co.uk/~ahey/em.png ./Data-COrdering/Data-COrdering.cabal:maintainer: http://homepages.nildram.co.uk/~ahey/em.png ./Data-Trie-General-OrdGT/dist/Data-Trie-General-OrdGT-0.4/Data-Trie-General-OrdGT.cabal:maintainer: http://homepages.nildram.co.uk/~ahey/em.png ./Data-Trie-General-OrdGT/Data-Trie-General-OrdGT.cabal:maintainer: http://homepages.nildram.co.uk/~ahey/em.png ./collections-base-instances/collections-base-instances.cabal:maintainer: jeanphilippe.bernardy (google mail) ./collections-base-instances/dist/collections-base-instances-0.4/collections-base-instances.cabal:maintainer: jeanphilippe.bernardy (google mail) ./collections-rangedsets-instances/collections-rangedsets-instances.cabal:maintainer: jeanphilippe.bernardy (google mail) ./collections-api/collections-api.cabal:maintainer: jeanphilippe.bernardy (google mail) ./collections-api/dist/collections-api-0.4/collections-api.cabal:maintainer: jeanphilippe.bernardy (google mail) ./enumsets/enumsets.cabal:maintainer: jeanphilippe.bernardy (google mail) ./enumsets/dist/enumsets-0.4/enumsets.cabal:maintainer: jeanphilippe.bernardy (google mail) ./collections-avl/dist/collections-avl-0.4/collections-avl.cabal:maintainer: jeanphilippe.bernardy (google mail) ./collections-avl/collections-avl.cabal:maintainer: jeanphilippe.bernardy (google mail) ./Data-Trie-General/Data-Trie-General.cabal:maintainer: http://homepages.nildram.co.uk/~ahey/em.png * Then I think the next step would be to remove whatever you've forked from the collections repo, & change the dependencies to depend on yours. But this assumes, I guess, that your versions haven't diverged too awfully far for the dependencies to fail. (So which ones are you maintaining, again?) > With regard to the maintenance state of packages in hackage, I think > it's fine to have dead/dormant/"looking for new owner" packages > archived there, just so long as it's clear to users that this is the > case (anyone who finds it useful enough to care about it's maintainance > can always take over ownership if they want). See my other email. To expand on my thoughts there, Hackage could add a warning if there is no maintainer field, show a maintainer entry on the webpage anyway but with the default author being one Mr. "Unmaintained". On a side note, I happened to run all my local repositories through find/grep, and I see that there are two examples of "maintainer: none"! Which supports my contention about variants, and I will amusedly note, outweighs the single usage of "maintainer: Unmaintained". > As it happens I think I probably will keep maintaining the AVL stuff > after all as the generalised tries package Jamie Brandon is working > on will probably have a dependency on it. > > Regards > -- > Adrian Hey -- gwern DI VIP J2 AFSPC detection STEEPLEBUSH DES chosen DDR&E RUOP -------------- 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/20080622/f6d81232/attachment.bin From ahey at iee.org Sun Jun 22 02:34:16 2008 From: ahey at iee.org (Adrian Hey) Date: Sun Jun 22 02:26:00 2008 Subject: Generic tries (long) In-Reply-To: <10ed1a750806210247h3474a629l58168bf2a885007b@mail.gmail.com> References: <10ed1a750806161228t12b974dx18395853e2b9e5f2@mail.gmail.com> <10ed1a750806181516o1e46cd7fp7d288631f20f9bd4@mail.gmail.com> <485A4EFF.2060901@iee.org> <10ed1a750806210247h3474a629l58168bf2a885007b@mail.gmail.com> Message-ID: <485DF268.7020600@iee.org> Hello Jamie, Jamie Brandon wrote: > I like focus, alter and merge. I've been thinking about the merge function. I think structurally it would be a bit like unionMaybe with mapMaybe applied to the non-overlapping bits. So it's hard to see how this could ever come close to the efficiency of the specialised union,intersection etc.. But it still looks like it could be useful in some situations (as a more efficient and flexible alternative to a union followed by a mapMaybe say), so would be worth implementing I think. ..and of course we'd probably want a version that didn't take keys as argument too. > If not, I dont want to have a class definition that makes it > difficult to write efficient implentations. I would rather have an > ugly class and a nicer layer on top. Yes, we don't want to go to all this trouble to produce "efficient" maps and then throw it all away in the name of elegance. MHO too is that if efficiency requires a big ugly class definition then let it be big and ugly :-) Regards -- Adrian Hey From ahey at iee.org Sun Jun 22 02:54:27 2008 From: ahey at iee.org (Adrian Hey) Date: Sun Jun 22 02:46:10 2008 Subject: Generic tries (long) In-Reply-To: References: <10ed1a750806161228t12b974dx18395853e2b9e5f2@mail.gmail.com> <10ed1a750806181516o1e46cd7fp7d288631f20f9bd4@mail.gmail.com> <485B8BBC.9030303@iee.org> Message-ID: <485DF723.3050106@iee.org> Hello apfelmus, apfelmus wrote: >> I've never been very keen on alter myself (on efficiency grounds) and >> was wondering whether of not to include it. If the "altering" results >> in an unchanged map it would be nice to just return the unchanged >> map (rather than duplicate all nodes on the search path). There are >> other possible alternatives to alter that are more efficient in this >> respect. > > You mean the case when > > f Nothing = Nothing or, for some a .. f (Just a) = Just a ..but of course there's no way you can tell from inside the alter function that the two a's are the same without an expensive equality test, and even then that's not enough because you need to pass the "no change" information back up the call chain (as a Nothing probably) which means that if there is a change even more heap will be burned by wrapping each intermediate result in a Just. > in alter f .. ? Hm, maybe some zipper-like extension of lookup can do > the trick > > focus :: k -> map a -> (Maybe a, Maybe a -> map a) > > lookup k = fst . focus k > delete k m = case focus k m of > (Nothing, _) -> m > (_ , g) -> g Nothing > alter f k m = case focus k m of > (Nothing, g) -> case f Nothing of > Nothing -> m > x -> g x > (x , g) -> g x I think it depends if this can be implemented without burning significant extra heap in either focus or the resulting g function. Generally zippers do require quite a bit of heap (proportional to trie/tree depth). If you consider what people are actually trying to achieve with alter I actually think it's rather easier to use as a 2 step process and forget about the (Maybe a -> Maybe a) function. After having done a lookup and examined the associated value (if any), you could do.. If search failed: 1f - Do nothing (this is a v. cheap operation :-) 2f - Insert a new association If search succeeded: 1s - Do nothing 2s - Modify the associated value 3s - Delete the association Despite it's generality, alter still fails to properly capture all the options, notably 1f and 1s. I guess it is conceivable that some implementations might be able to deal with 1f efficiently. For the Data.Map clone I wrote something like this .. -- An "open" map (this is abstract) data OMap k a = OMap k (Maybe a) (Map k a) Int# -- This is just a lookup that encodes the path taken as an unboxed Int open :: Ord k => k -> Map k a -> OMap k a -- Get the current associated value (if any) read :: OMap k a -> Maybe a -- Change the current associated value and close the new map -- This is v.fast. No comparisons, and no balance checking or -- rebalancing either if this is a substitution rather than an -- insertion. write :: a -> OMap k a -> Map k a -- Delete the current association (if any) and close the new map -- This is nop if there is no current association delete :: OMap k a -> Map k a -- Not really needed if original map is still in scope close :: OMap k a -> Map k a open burns no heap at all other than to construct the OMap record (possibly not even that) and possibly the (Just a). If it turns out there's no need to write or delete then don't (end of story). Even if a write is needed the whole combined process only takes about 10% longer than a normal insert, and that's with cheap comparisons (Ints). Admitedly for a trie the path would probably be something a bit more complex than an unboxed Int, but we could use a similar API. Regards -- Adrian Hey From ahey at iee.org Sun Jun 22 03:45:34 2008 From: ahey at iee.org (Adrian Hey) Date: Sun Jun 22 03:37:16 2008 Subject: Generic tries (long) In-Reply-To: <5ab17e790806210831m10b8addar56dce4eeb34b167@mail.gmail.com> References: <10ed1a750806161228t12b974dx18395853e2b9e5f2@mail.gmail.com> <5ab17e790806210831m10b8addar56dce4eeb34b167@mail.gmail.com> Message-ID: <485E031E.2020303@iee.org> Hello Iavor, Iavor Diatchki wrote: > thanks for doing this---I think that the functions in the API look > good. Of course, one can always think of more :-) One that I often > find useful when working with Data.Map is a function that removes a > key from a map and also returns the associated value---a kind of > destructive lookup. That would be good. I guess you could implement that using the OMap idea I just posted, or you could have a specialised lookupDelete method. > I think that the library would be better if you exposed a > non-overloaded API for the map(s?) that you plan to implement. This > is useful because (i) most of the type I anticipiate using a single > type of map, and concrete types lead to more accurate types in type > inference, (ii) it makes the API Haskell'98 and hence likely to work > on most Haskell implementations out there. If you really think that > the overloading is useful, then you could provide separate modules > that provide the class+instances in terms of the non-overloaded API > and add a cabal flag to turn these on/off. I agree, all the hand written instances I've written so far do expose the non-overloaded function names. The instance declarations are just simple renamings. However, the polymorphic versions still have appropriate class constraints so probably still won't work with any Haskell that doesn't understand the class. Things may not be so simple with automated deriving because of the difficulty of adding to module export lists. But I guess with bit of that cpp hackery thrown in this is not too much of a problem :-) > Also, as others mentioned, using Int# in an API is not great because > this is a GHC internal type. If you found situatuins where GHC is not > unboxing something please send a mail to the GHC team---they are > usually very good at fixing these sorts of things. Adrian mentioned > that you use CPP to control the use of Int# but this does not help if > the Int# leaks through the API: (i) I could still have programs that > work in Hugs and fail to compile in GHC (and vice versa), (ii) if I > want to use your map library, I would have to compile all my programs > with the CPP extensions, which is not nice. Well I may be wrong, but AFAIK as we're talking about a class method here if boxed is what you specify, boxed is what you will get. It *might* be converted to unboxed if you use a SPECIALISE pragma, but this kind of optimisation depends on strictness analysis. It's very easy to end up writing something that is non-strict (or is strict but ghc can't see it) and lose the unboxing. I haven't been keeping up with H', but I would hope that support for unboxed (or should I say unpointed?) types would be part of that. Regards -- Adrian Hey From apfelmus at quantentunnel.de Sun Jun 22 07:10:04 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Sun Jun 22 07:01:54 2008 Subject: Generic tries (long) In-Reply-To: <485DF723.3050106@iee.org> References: <10ed1a750806161228t12b974dx18395853e2b9e5f2@mail.gmail.com> <10ed1a750806181516o1e46cd7fp7d288631f20f9bd4@mail.gmail.com> <485B8BBC.9030303@iee.org> <485DF723.3050106@iee.org> Message-ID: Adrian Hey wrote: > For the Data.Map clone I wrote something like this .. > > -- An "open" map (this is abstract) > data OMap k a = OMap k (Maybe a) (Map k a) Int# > > -- This is just a lookup that encodes the path taken as an unboxed Int > open :: Ord k => k -> Map k a -> OMap k a > > -- Get the current associated value (if any) > read :: OMap k a -> Maybe a > > -- Change the current associated value and close the new map > -- This is v.fast. No comparisons, and no balance checking or > -- rebalancing either if this is a substitution rather than an > -- insertion. > write :: a -> OMap k a -> Map k a > > -- Delete the current association (if any) and close the new map > -- This is nop if there is no current association > delete :: OMap k a -> Map k a > > -- Not really needed if original map is still in scope > close :: OMap k a -> Map k a > I think it depends if this can be implemented without burning > significant extra heap in either focus or the resulting g function. > Generally zippers do require quite a bit of heap (proportional to > trie/tree depth). The OMap type is like a zipper, the Int# encodes the path. I don't know whether the Int# (which should be a !Int with an UNPACK pragma) really gains anything compared to a list, only benchmarks can tell. Fretting about it seems like an irrelevant micro-optimization to me. In any case, focus can easily be implemented in terms of OMap : focus :: k -> map a -> (Maybe a, Maybe a -> map a) focus k m = (read z, maybe (delete z) (`write` z)) where z = open k m So any efficient implementation for OMap gives an efficient implementation for focus . And vice-versa type OMap k a = (Maybe a, Maybe a -> Map k a) open = focus read = fst write x = ($ Just x ) . snd delete = ($ Nothing) . snd Regards, apfelmus From jyasskin at gmail.com Sun Jun 22 13:46:14 2008 From: jyasskin at gmail.com (Jeffrey Yasskin) Date: Sun Jun 22 13:37:53 2008 Subject: Generic tries (long) In-Reply-To: <485DF723.3050106@iee.org> References: <10ed1a750806161228t12b974dx18395853e2b9e5f2@mail.gmail.com> <10ed1a750806181516o1e46cd7fp7d288631f20f9bd4@mail.gmail.com> <485B8BBC.9030303@iee.org> <485DF723.3050106@iee.org> Message-ID: <5d44f72f0806221046mf2c4b8fp2d6f3de14492954f@mail.gmail.com> On Sat, Jun 21, 2008 at 11:54 PM, Adrian Hey wrote: > Hello apfelmus, > > apfelmus wrote: >>> >>> I've never been very keen on alter myself (on efficiency grounds) and >>> was wondering whether of not to include it. If the "altering" results >>> in an unchanged map it would be nice to just return the unchanged >>> map (rather than duplicate all nodes on the search path). There are >>> other possible alternatives to alter that are more efficient in this >>> respect. >> >> You mean the case when >> >> f Nothing = Nothing > > or, for some a .. > > f (Just a) = Just a > > ..but of course there's no way you can tell from inside the alter > function that the two a's are the same without an expensive equality > test, and even then that's not enough because you need to pass the > "no change" information back up the call chain (as a Nothing probably) > which means that if there is a change even more heap will be burned > by wrapping each intermediate result in a Just. Thinking as a C++ programmer for a bit, I'd want to implement this as a pointer comparison. If the argument to alter returns the same object (not just an equal one), then the implementation can cheaply avoid creating the new sub-tree. If it returns an equal one, you'd like to skip the copy, but it's not worth the equality test. Is there a reason I'm missing that it's a bad idea to use GHS.Prim.reallyUnsafePtrEquality# or a similar low-level function in the alter implementation? If alter were to cheat like this, we'd want to write its argument as: f n@Nothing = n f j@(Just a) = j instead of risking creating a new object. Trying this out, I figured out why it's called "reallyUnsafe": Prelude GHC.Exts GHC.Prim> let q = Just 3 Prelude GHC.Exts GHC.Prim> let f j@(Just a) = j; r = f q Prelude GHC.Exts GHC.Prim> I# (reallyUnsafePtrEquality# q r) 0 Prelude GHC.Exts GHC.Prim> r Just 3 Prelude GHC.Exts GHC.Prim> I# (reallyUnsafePtrEquality# q r) 1 Prelude GHC.Exts GHC.Prim> and even stranger: Prelude GHC.Exts GHC.Prim> let q = Just 3 Prelude GHC.Exts GHC.Prim> let f j@(Just a) = j; r = f q Prelude GHC.Exts GHC.Prim> I# (r `seq` reallyUnsafePtrEquality# q r) 0 Prelude GHC.Exts GHC.Prim> I# (r `seq` reallyUnsafePtrEquality# q r) 1 So it'd take some doing to get the implementation right, but getting the fully-general API without wasting allocations might be worth it. Jeffrey From lemming at henning-thielemann.de Sun Jun 22 16:39:28 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun Jun 22 16:31:07 2008 Subject: Generic tries (long) In-Reply-To: <5ab17e790806210831m10b8addar56dce4eeb34b167@mail.gmail.com> References: <10ed1a750806161228t12b974dx18395853e2b9e5f2@mail.gmail.com> <5ab17e790806210831m10b8addar56dce4eeb34b167@mail.gmail.com> Message-ID: On Sat, 21 Jun 2008, Iavor Diatchki wrote: > Hi Jamie, > > thanks for doing this---I think that the functions in the API look > good. Of course, one can always think of more :-) One that I often > find useful when working with Data.Map is a function that removes a > key from a map and also returns the associated value---a kind of > destructive lookup. > > I think that the library would be better if you exposed a > non-overloaded API for the map(s?) that you plan to implement. This > is useful because (i) most of the type I anticipiate using a single > type of map, and concrete types lead to more accurate types in type > inference, (ii) it makes the API Haskell'98 and hence likely to work > on most Haskell implementations out there. If you really think that > the overloading is useful, then you could provide separate modules > that provide the class+instances in terms of the non-overloaded API > and add a cabal flag to turn these on/off. That's certainly not a good idea, since other modules must be sure, that if package generic-tries is installed that then the advanced API is available. Thus the advanced API must be moved to a separate package. (I prefer that separation.) From jcb73 at cam.ac.uk Sun Jun 22 23:38:11 2008 From: jcb73 at cam.ac.uk (Jamie Brandon) Date: Sun Jun 22 23:29:47 2008 Subject: Generic tries (long) In-Reply-To: References: <10ed1a750806161228t12b974dx18395853e2b9e5f2@mail.gmail.com> <5ab17e790806210831m10b8addar56dce4eeb34b167@mail.gmail.com> Message-ID: <10ed1a750806222038u1cc3379cp6136d2431ce5a003@mail.gmail.com> Ive added the rest of Adrian's functions to the api, largely without change. Still living at http://code.haskell.org/gmap/api/GMap.html The Serial code is now *finished* and tested and is living at http://code.haskell.org/gmap/serial . The user level interface is largely the same as Data.Binary, on which it is based: *Data.Serial> encode "supercalifragilisticexpialidociousness" :: [Word] [1401017574,815320646,2442711660,441247251,3504761142,212218697,3261675550,3863169456,1865717965,1399966954,6082150] I'll get to work on some benchmark now so I can see how efficiently the simple version of the api can be implemented. It doesnt really seem worth arguing over it until we have some numbers. I would hope that if merge and the associated comparison functions are declared inlinable then ghc should be able to mostly recover the original, efficient implementations. Cheers Jamie From ross at soi.city.ac.uk Mon Jun 23 05:05:59 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Jun 23 04:57:37 2008 Subject: agreeing a policy for maintainers and hackageDB Message-ID: <20080623090559.GA2836@soi.city.ac.uk> As a few people have noted, we need to agree a policy in this area. As I see it, the drivers are: * users need to know whether what they're downloading is supported, and if so by whom. * maintainers are entitled to control what goes out in their name. * allocating version numbers for a particular package name should be the prerogative of the maintainer. When something is agreed, I propose to put it on the hackageDB upload page and expect people to follow it. Here's my first attempt: If the Maintainer field names a person or group, the release as a whole (including packaging) is the named maintainer's approved release, which they are supporting (at least for some time after the release). Ideally a maintainer would make that clear by uploading the release themselves. A Maintainer value of "none" indicates that the package is not supported. If a package is being maintained, any release not approved and supported by the maintainer should use a different package name. Then use the Maintainer field as above either to commit to supporting the fork yourself or to mark it as unsupported. From ahey at iee.org Mon Jun 23 06:02:52 2008 From: ahey at iee.org (Adrian Hey) Date: Mon Jun 23 05:54:29 2008 Subject: Generic tries (long) In-Reply-To: <485B8BBC.9030303@iee.org> References: <10ed1a750806161228t12b974dx18395853e2b9e5f2@mail.gmail.com> <10ed1a750806181516o1e46cd7fp7d288631f20f9bd4@mail.gmail.com> <485B8BBC.9030303@iee.org> Message-ID: <485F74CC.8080504@iee.org> Adrian Hey wrote: > I've never been very keen on alter myself (on efficiency grounds) and > was wondering whether of not to include it. If the "altering" results > in an unchanged map it would be nice to just return the unchanged > map (rather than duplicate all nodes on the search path). There are > other possible alternatives to alter that are more efficient in this > respect. There's something else that's always bugged me about alter. I'm sure I can't be the only one who thinks requiring me to define a function like this is a very weird thing to do... f :: Maybe a -> Maybe a f Nothing = maybea -- A constant, either Nothing or (Just somea) f (Just a) = f' a I've never felt comfortable with this. In any case I realised that alter can be easily implemented using other class primitives alter f k map = case f Nothing of Just somea -> insertMaybe f' k somea map Nothing -> deleteMaybe f' k map where f' a = f (Just a) but since I know what maybea and f' are, it seems to me it's a lot easier to just use f' directly in either insertMaybe or deleteMaybe as appropriate (depending on maybea). The type of the proposed merge now seems similarly strange to me.. merge :: (k -> Maybe a -> Maybe b -> Maybe c) -> map a -> map b -> map c This requres users to define a function argument that is presumably of form.. f k Nothing Nothing = undefined f k (Just a) Nothing = fa k a f k (Just a) (Just b) = fab k a b f k Nothing (Just b) = fb k b Why not just pass fa,fab and fb directly, which will be more convenient for both users and implementors I think.. merge :: (k -> a -> Maybe c) -> (k -> a -> b -> Maybe c) -> (k -> b -> Maybe c) -> map a -> map b -> map c Though I actually think if this is to be included perhaps it should be called mergeMaybeWithKey, and we also have.. mergeMaybe :: (a -> Maybe c) -> (a -> b -> Maybe c) -> ( b -> Maybe c) -> map a -> map b -> map c merge :: (a -> c) -> (a -> b -> c) -> ( b -> c) -> map a -> map b -> map c mergeWithKey :: (k -> a -> c) -> (k -> a -> b -> c) -> (k -> b -> c) -> map a -> map b -> map c Regards -- Adrian Hey From duncan.coutts at worc.ox.ac.uk Mon Jun 23 06:14:51 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Jun 23 06:01:25 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: <20080623090559.GA2836@soi.city.ac.uk> References: <20080623090559.GA2836@soi.city.ac.uk> Message-ID: <1214216091.15010.1016.camel@localhost> On Mon, 2008-06-23 at 10:05 +0100, Ross Paterson wrote: > As a few people have noted, we need to agree a policy in this area. > As I see it, the drivers are: > > * users need to know whether what they're downloading is supported, > and if so by whom. > * maintainers are entitled to control what goes out in their name. > * allocating version numbers for a particular package name should be > the prerogative of the maintainer. > > When something is agreed, I propose to put it on the hackageDB upload > page and expect people to follow it. Here's my first attempt: > > If the Maintainer field names a person or group, the release as > a whole (including packaging) is the named maintainer's approved > release, which they are supporting (at least for some time after > the release). Ideally a maintainer would make that clear by > uploading the release themselves. > > A Maintainer value of "none" indicates that the package is > not supported. > > If a package is being maintained, any release not approved and > supported by the maintainer should use a different package name. > Then use the Maintainer field as above either to commit to > supporting the fork yourself or to mark it as unsupported. Looks good to me, except that I think I agree with Gwern that an empty maintainer field is better than a distinguished value like "none". We can always make the web page note that the package has no maintainer. If on the other hand everyone thinks "none" is a good idea then we should make hackage upload enforce that the maintainer field is not empty. Duncan From ross at soi.city.ac.uk Mon Jun 23 06:34:44 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Jun 23 06:26:21 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: <1214216091.15010.1016.camel@localhost> References: <20080623090559.GA2836@soi.city.ac.uk> <1214216091.15010.1016.camel@localhost> Message-ID: <20080623103444.GA2969@soi.city.ac.uk> On Mon, Jun 23, 2008 at 11:14:51AM +0100, Duncan Coutts wrote: > On Mon, 2008-06-23 at 10:05 +0100, Ross Paterson wrote: > > A Maintainer value of "none" indicates that the package is > > not supported. > > Looks good to me, except that I think I agree with Gwern that an empty > maintainer field is better than a distinguished value like "none". I don't mind whether the distinguished value is "", "none" or something else, just that there is one. I suppose the empty string is easier to get right. From isaacdupree at charter.net Mon Jun 23 06:56:12 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Mon Jun 23 06:47:59 2008 Subject: [Haskell-cafe] ANNOUNCE: Pipe 1.0 In-Reply-To: <20080621191255.GA2361@scytale.galois.com> References: <20080621191255.GA2361@scytale.galois.com> Message-ID: <485F814C.7090105@charter.net> Don Stewart wrote: > Interesting. > Does it depend on an unreleased version of the process library? by the way, is there a policy for when new versions of packages maintained by libraries@h.o are *released*? Or do patches just collect in the darcs repository until they're picked up by some major release like GHC's? I would tend to think that for any change nontrivial enough to be discussed on libraries@, why not quickly release the newer version with an appropriately incremented version number? -Isaac From isaacdupree at charter.net Mon Jun 23 08:28:59 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Mon Jun 23 08:20:47 2008 Subject: Generic tries (long) In-Reply-To: <485E031E.2020303@iee.org> References: <10ed1a750806161228t12b974dx18395853e2b9e5f2@mail.gmail.com> <5ab17e790806210831m10b8addar56dce4eeb34b167@mail.gmail.com> <485E031E.2020303@iee.org> Message-ID: <485F970B.9000307@charter.net> >> Also, as others mentioned, using Int# in an API is not great because >> this is a GHC internal type. If you found situatuins where GHC is not >> unboxing something please send a mail to the GHC team---they are >> usually very good at fixing these sorts of things. Adrian mentioned >> that you use CPP to control the use of Int# but this does not help if >> the Int# leaks through the API: (i) I could still have programs that >> work in Hugs and fail to compile in GHC (and vice versa), (ii) if I >> want to use your map library, I would have to compile all my programs >> with the CPP extensions, which is not nice. > > Well I may be wrong, but AFAIK as we're talking about a class method > here if boxed is what you specify, boxed is what you will get. It > *might* be converted to unboxed if you use a SPECIALISE pragma, but > this kind of optimisation depends on strictness analysis. It's very > easy to end up writing something that is non-strict (or is strict but > ghc can't see it) and lose the unboxing. this is where we need, hmm, if in the class there was size :: map a -> Int# one would like something such as size :: map a -> {-# UNPACK #-} Int to work, since that unboxing doesn't change the semantics (results are implicitly lifted...). But as it is addSize :: map a -> UINT -> UINT foldElemsUINT :: (a -> UINT -> UINT) -> map a -> UINT -> UINT we also need something like John Meacham's ! and ~ stuff in class methods, to force strictness (because that changes the semantics). It could get ugly, since GHC tries to preserve sharing by default, so we always need UNPACK: addSize :: map a -> {-#UNPACK#-}!Int -> {-#UNPACK#-}Int Reminds me a little of http://hackage.haskell.org/trac/ghc/ticket/1349 because functions in data and in classes suffer the same "openness" problem that you can't know, given separate compilation, what functions are going to be used to implement that - so you can't optimize for them so well. -Isaac From marlowsd at gmail.com Mon Jun 23 09:14:14 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Jun 23 09:05:54 2008 Subject: ANNOUNCE: Pipe 1.0 In-Reply-To: <485F814C.7090105@charter.net> References: <20080621191255.GA2361@scytale.galois.com> <485F814C.7090105@charter.net> Message-ID: <485FA1A6.9040208@gmail.com> Isaac Dupree wrote: > Don Stewart wrote: >> Interesting. >> Does it depend on an unreleased version of the process library? > > by the way, is there a policy for when new versions of packages > maintained by libraries@h.o are *released*? Or do patches just collect > in the darcs repository until they're picked up by some major release > like GHC's? I would tend to think that for any change nontrivial enough > to be discussed on libraries@, why not quickly release the newer version > with an appropriately incremented version number? There are some further changes we've been discussing, see Duncan's message here: http://www.haskell.org/pipermail/libraries/2008-May/009695.html and I'd like to batch all these together in one release. Cheers, Simon From ahey at iee.org Mon Jun 23 12:58:42 2008 From: ahey at iee.org (Adrian Hey) Date: Mon Jun 23 12:50:18 2008 Subject: Generic tries (long) In-Reply-To: References: <10ed1a750806161228t12b974dx18395853e2b9e5f2@mail.gmail.com> <10ed1a750806181516o1e46cd7fp7d288631f20f9bd4@mail.gmail.com> <485B8BBC.9030303@iee.org> <485DF723.3050106@iee.org> Message-ID: <485FD642.20804@iee.org> Hello apfelmus, apfelmus wrote: > The OMap type is like a zipper, the Int# encodes the path. I don't know > whether the Int# (which should be a !Int with an UNPACK pragma) really > gains anything compared to a list, only benchmarks can tell. Fretting > about it seems like an irrelevant micro-optimization to me. Actually MHO is that using proper language constructs (where available) is always preferable to pragma or compliler flag hackery :-) As for this kind of thing being irrelevant micro-optimization, this is not the case. If you consider what a typical Haskell prog spends it's time doing.. 1 - Traversing heap data structures 2 - Building new heap records 3 - Collecting garbage Excessive heap allocation rate has a big impact on time spent on both 2 and 3, and hence on overall performance. A fact that has been confirmed in just about every benchmark I've ever run. Here's the results of one I posted recently http://www.haskell.org/pipermail/haskell-cafe/2008-February/039882.html So if performance is a concern, MHO is that heap allocation should be avoided like the proverbial plague. In a world of immutable data structures it's always likely to be on the high side anyway, but anything that can be done to reduce it will boost performance. I do think a general purpose zipper would be a great thing to have, especially for ordered maps. But for the particular problem that sparked this discussion I suspect (though I don't know) that it might be expensive overkill. It needs thinking about. (There's at least one case I know of where there is a much cheaper solution.) > In any case, focus can easily be implemented in terms of OMap : Yes, of course. The point I was trying to make about OMap was that if we're going to have full zipper available, one where you could actually "walk the map", inspecting, modifying, inserting and deleting as you go (call it ZMap say), then the OMap distinction with (corresponding impoverished API) is useful. Just making the point that the OMap or something like it is all that's needed to solve this particular problem (if it can be implemented cheaply). Regards -- Adrian Hey From ahey at iee.org Mon Jun 23 14:57:59 2008 From: ahey at iee.org (Adrian Hey) Date: Mon Jun 23 14:49:37 2008 Subject: Generic tries (long) In-Reply-To: <5d44f72f0806221046mf2c4b8fp2d6f3de14492954f@mail.gmail.com> References: <10ed1a750806161228t12b974dx18395853e2b9e5f2@mail.gmail.com> <10ed1a750806181516o1e46cd7fp7d288631f20f9bd4@mail.gmail.com> <485B8BBC.9030303@iee.org> <485DF723.3050106@iee.org> <5d44f72f0806221046mf2c4b8fp2d6f3de14492954f@mail.gmail.com> Message-ID: <485FF237.5040604@iee.org> Hello Jeffrey, Jeffrey Yasskin wrote: > Is there a reason > I'm missing that it's a bad idea to use > GHS.Prim.reallyUnsafePtrEquality# or a similar low-level function in > the alter implementation? I think, given the fuss about unboxed Ints, most people would recoil in horror at this :-) I guess what you could do would be to have the function argument of alter and friends return a type (Maybe (Maybe a)) where.. Nothing means delete it Just Nothing means leave it alone Just (Just a) means use a as the new associated value. ..then to pass the change/nochange information back up the call chain you could use an unboxed pair result containing an appropriate Bool in addition to the (possibly modified) subtree. But I can't help wondering if all the functions like this are really the wrong abstraction. They might be what you want sometimes, but often you'd want to combine them with a lookup (without searching the map twice in quick succession using the same key). Something like the proposed zipper based focus, OMap or whatever seems much more general purpose, flexible and easy to use. It's just a question of whether or not it can be implemented efficiently enough to make alter and friends obsolete (at least as class methods), or should it be an addition to an API that still retains alter (deleteMaybe etc..). Regards -- Adrian Hey From haskell at list.mightyreason.com Mon Jun 23 15:38:14 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Mon Jun 23 15:30:00 2008 Subject: Package spam :-) In-Reply-To: <20080622055923.GB30974@craft> References: <4858F398.20708@iee.org> <20080618201125.GG24043@scytale.galois.com> <20080619160646.GA21711@craft> <200806192124.37772.dan.doel@gmail.com> <953e0d250806200101l643878ceq480a22c5906ce8c@mail.gmail.com> <20080620090626.GA2361@soi.city.ac.uk> <20080620184917.GB31722@scytale.galois.com> <20080622055923.GB30974@craft> Message-ID: <485FFBA6.4020900@list.mightyreason.com> Gwern Branwen wrote: > On 2008.06.20 11:49:17 -0700, Don Stewart scribbled 0.9K characters: >> ross: >>> On Fri, Jun 20, 2008 at 10:01:29AM +0200, Jean-Philippe Bernardy wrote: >>>> We already discussed this before, but that repository can be >>>> considered orphaned. I'll give pointers to anybody interested in >>>> adopting it. >>> Thanks for the clarification, Jean-Philippe. >>> >>> On the broader issue, personally I'd prefer not to have non-maintained >>> packages on hackageDB (because their presence lowers people's expectations >>> of the whole collection) but others disagree on that point. If we must >>> have them, they ought not to be marked as maintained. It's not fair on >>> users, or on the person named as maintainer. >> Perhaps if the .cabal files for orphaned packages could be >> marked as, say: >> >> maintainer: unmaintained >> >> or >> >> maintainer: orphaned >> >> This might alleviate some problems (a future hackage could filter >> unmaintained packages). >> >> Gwern, would that work for you, for these library salvaging efforts? >> >> -- Don > > This *would* work for me; however, there is a reason I haven't done this or something like it before (and instead simply omitted the maintainer: field whenever I thought something was unmaintained). > > Fundamentally, I feel that putting something like into the free-form text field is kind of abusing it, that there should be some more structured way. As you've already pointed out, when a package is unmaintained, what is the canonical machine-readable way of saying so? > > We have such ways of specifying dependencies and tested-status, which is good > for cabal-install. But what about maintainedness? Is it "unmaintained"? "unsupported"? "Unsupported"? "orphaned"? "Orphaned"? I can tell you just from past experience with the stability: field* that people will use all those and more if we don't give them a clear and unambiguous restriction on what can be put in - and then how will Hackage programmatically filter out unmaintained stuff? > > The status quo of not listing maintainer at least is programmatic - if > there's a maintainer field, it's maintained by the person listed; if not, not. We could formalize this a little bit. For example, the cabal tools see an omitted maintainer field as a problem, not as a valid choice, and Hackage does nothing based on an omission. These are relatively small tweaks, though. What's the alternative? some sort of data Maintainer = None | Maintained String? But how could you then make maintainer: backwards compatible...? Add an entirely new field? (maintained: True) But then we wouldn't see it in sufficiently wide-spread use to be usable for years and years. > > * Which needs to be fixed for all the reasons I've listed here for maintainer:; see . Here is another view: The use of a cabal field to indicate orphan seems wrong to me. The maintainer field in the cabal file currently indicates who was responsible for and interested in such things as bug reports and patches at the time of the release of that version of that package. The orphan state is associated with the package's basename, not any given version of the package. I think of "orphan" vs "non-orphan" as associated with promised future versions of the package. In an extreme case, the orphan status could change several times in a day. Things at this level of abstraction should be tracked by a future version of hackage. What expectations should a user have when a package: has an Author? has a Maintainer? is an orphan? is supported? is unsupported? -- Chris From duncan.coutts at worc.ox.ac.uk Mon Jun 23 17:40:18 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Jun 23 17:27:00 2008 Subject: Package spam :-) In-Reply-To: <485FFBA6.4020900@list.mightyreason.com> References: <4858F398.20708@iee.org> <20080618201125.GG24043@scytale.galois.com> <20080619160646.GA21711@craft> <200806192124.37772.dan.doel@gmail.com> <953e0d250806200101l643878ceq480a22c5906ce8c@mail.gmail.com> <20080620090626.GA2361@soi.city.ac.uk> <20080620184917.GB31722@scytale.galois.com> <20080622055923.GB30974@craft> <485FFBA6.4020900@list.mightyreason.com> Message-ID: <1214257218.15010.1041.camel@localhost> On Mon, 2008-06-23 at 20:38 +0100, Chris Kuklewicz wrote: > Here is another view: The use of a cabal field to indicate orphan seems wrong to me. > > The maintainer field in the cabal file currently indicates who was responsible > for and interested in such things as bug reports and patches at the time of the > release of that version of that package. Right. > The orphan state is associated with the package's basename, not any given > version of the package. I think of "orphan" vs "non-orphan" as associated with > promised future versions of the package. In an extreme case, the orphan status > could change several times in a day. Things at this level of abstraction should > be tracked by a future version of hackage. Yes. I agree. It's not even necessarily the author themselves that would necessarily mark a package as obsolete or without maintainers or whatever. It might be some other person doing package collection maintenance (a job rather like what distro packaging people do). Duncan From duncan.coutts at worc.ox.ac.uk Mon Jun 23 17:51:43 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Jun 23 17:38:13 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: <20080623090559.GA2836@soi.city.ac.uk> References: <20080623090559.GA2836@soi.city.ac.uk> Message-ID: <1214257903.15010.1053.camel@localhost> If a few more people could read this nice short policy and say "yes that looks fine, I agree" then that would be very helpful. If this is to be something that we put on hackage and expect people to follow then it needs to be *seen* to be supported by people in the community. If we need to act on the policy we don't want to be open to the accusation that the policy was just imposed by Cabal bureaucrats hell-bent on spoiling people's fun but that it actually reflects the general view of the Haskell hacker community. Just because it isn't controversial doesn't mean we don't need your support! :-) Of course if you do have any questions or suggestions then now is a good time to mention them. Duncan On Mon, 2008-06-23 at 10:05 +0100, Ross Paterson wrote: > As a few people have noted, we need to agree a policy in this area. > As I see it, the drivers are: > > * users need to know whether what they're downloading is supported, > and if so by whom. > * maintainers are entitled to control what goes out in their name. > * allocating version numbers for a particular package name should be > the prerogative of the maintainer. > > When something is agreed, I propose to put it on the hackageDB upload > page and expect people to follow it. Here's my first attempt: > > If the Maintainer field names a person or group, the release as > a whole (including packaging) is the named maintainer's approved > release, which they are supporting (at least for some time after > the release). Ideally a maintainer would make that clear by > uploading the release themselves. > > A Maintainer value of "none" indicates that the package is > not supported. > > If a package is being maintained, any release not approved and > supported by the maintainer should use a different package name. > Then use the Maintainer field as above either to commit to > supporting the fork yourself or to mark it as unsupported. From ndmitchell at gmail.com Mon Jun 23 18:06:35 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Jun 23 17:58:10 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: <1214257903.15010.1053.camel@localhost> References: <20080623090559.GA2836@soi.city.ac.uk> <1214257903.15010.1053.camel@localhost> Message-ID: <404396ef0806231506r50320a8h4c95af327da657f@mail.gmail.com> Hi (+1) Support, with two things: 1) I agree with Duncan. I think blank is a much better field name than "none". What if Mr None wants to maintain a package :-) Another reason is that its less likely to go wrong, and valid in any language. 2) " If a package is being maintained, any release not approved and supported by the maintainer should use a different package name. Then use the Maintainer field as above either to commit to supporting the fork yourself or to mark it as unsupported." I would change the final sentance to: "Then put your own name in the Maintainer field, to indicate your ongoing support for the package." People will figure out that if they want to fork and abandon then they can blank the maintainer field, but by default a fork should come with support. We don't want to enourage one-shot packages with no support! But that's a minor thing, and if people want to leave it as it is then that's fine. Thanks Neil On 6/23/08, Duncan Coutts wrote: > If a few more people could read this nice short policy and say "yes that > looks fine, I agree" then that would be very helpful. > > If this is to be something that we put on hackage and expect people to > follow then it needs to be *seen* to be supported by people in the > community. If we need to act on the policy we don't want to be open to > the accusation that the policy was just imposed by Cabal bureaucrats > hell-bent on spoiling people's fun but that it actually reflects the > general view of the Haskell hacker community. > > Just because it isn't controversial doesn't mean we don't need your > support! :-) > > Of course if you do have any questions or suggestions then now is a good > time to mention them. > > > Duncan > > > On Mon, 2008-06-23 at 10:05 +0100, Ross Paterson wrote: > > > As a few people have noted, we need to agree a policy in this area. > > As I see it, the drivers are: > > > > * users need to know whether what they're downloading is supported, > > and if so by whom. > > * maintainers are entitled to control what goes out in their name. > > * allocating version numbers for a particular package name should be > > the prerogative of the maintainer. > > > > When something is agreed, I propose to put it on the hackageDB upload > > page and expect people to follow it. Here's my first attempt: > > > > If the Maintainer field names a person or group, the release as > > a whole (including packaging) is the named maintainer's approved > > release, which they are supporting (at least for some time after > > the release). Ideally a maintainer would make that clear by > > uploading the release themselves. > > > > A Maintainer value of "none" indicates that the package is > > not supported. > > > > If a package is being maintained, any release not approved and > > supported by the maintainer should use a different package name. > > Then use the Maintainer field as above either to commit to > > supporting the fork yourself or to mark it as unsupported. > > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From niklas.broberg at gmail.com Mon Jun 23 18:12:02 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Mon Jun 23 18:03:37 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: <404396ef0806231506r50320a8h4c95af327da657f@mail.gmail.com> References: <20080623090559.GA2836@soi.city.ac.uk> <1214257903.15010.1053.camel@localhost> <404396ef0806231506r50320a8h4c95af327da657f@mail.gmail.com> Message-ID: +1 from me too, and I agree with the points raised by Neil. Cheers, /Niklas On 6/24/08, Neil Mitchell wrote: > Hi > > (+1) Support, with two things: > > 1) I agree with Duncan. I think blank is a much better field name than > "none". What if Mr None wants to maintain a package :-) Another reason > is that its less likely to go wrong, and valid in any language. > > 2) " If a package is being maintained, any release not approved and > > supported by the maintainer should use a different package name. > Then use the Maintainer field as above either to commit to > supporting the fork yourself or to mark it as unsupported." > > > I would change the final sentance to: "Then put your own name in the > Maintainer field, to indicate your ongoing support for the package." > People will figure out that if they want to fork and abandon then they > can blank the maintainer field, but by default a fork should come with > support. We don't want to enourage one-shot packages with no support! > > But that's a minor thing, and if people want to leave it as it is then > that's fine. > > Thanks > > > Neil > > > > > On 6/23/08, Duncan Coutts wrote: > > If a few more people could read this nice short policy and say "yes that > > looks fine, I agree" then that would be very helpful. > > > > If this is to be something that we put on hackage and expect people to > > follow then it needs to be *seen* to be supported by people in the > > community. If we need to act on the policy we don't want to be open to > > the accusation that the policy was just imposed by Cabal bureaucrats > > hell-bent on spoiling people's fun but that it actually reflects the > > general view of the Haskell hacker community. > > > > Just because it isn't controversial doesn't mean we don't need your > > support! :-) > > > > Of course if you do have any questions or suggestions then now is a good > > time to mention them. > > > > > > Duncan > > > > > > On Mon, 2008-06-23 at 10:05 +0100, Ross Paterson wrote: > > > > > As a few people have noted, we need to agree a policy in this area. > > > As I see it, the drivers are: > > > > > > * users need to know whether what they're downloading is supported, > > > and if so by whom. > > > * maintainers are entitled to control what goes out in their name. > > > * allocating version numbers for a particular package name should be > > > the prerogative of the maintainer. > > > > > > When something is agreed, I propose to put it on the hackageDB upload > > > page and expect people to follow it. Here's my first attempt: > > > > > > If the Maintainer field names a person or group, the release as > > > a whole (including packaging) is the named maintainer's approved > > > release, which they are supporting (at least for some time after > > > the release). Ideally a maintainer would make that clear by > > > uploading the release themselves. > > > > > > A Maintainer value of "none" indicates that the package is > > > not supported. > > > > > > If a package is being maintained, any release not approved and > > > supported by the maintainer should use a different package name. > > > Then use the Maintainer field as above either to commit to > > > supporting the fork yourself or to mark it as unsupported. > > > > > > _______________________________________________ > > 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 23 18:29:37 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Mon Jun 23 18:21:09 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: References: <20080623090559.GA2836@soi.city.ac.uk> <1214257903.15010.1053.camel@localhost> <404396ef0806231506r50320a8h4c95af327da657f@mail.gmail.com> Message-ID: <486023D1.7020302@charter.net> +1 also Niklas Broberg wrote: > +1 from me too, and I agree with the points raised by Neil. > > Cheers, > > /Niklas > > On 6/24/08, Neil Mitchell wrote: >> Hi >> >> (+1) Support, with two things: >> >> 1) I agree with Duncan. I think blank is a much better field name than >> "none". What if Mr None wants to maintain a package :-) Another reason >> is that its less likely to go wrong, and valid in any language. >> >> 2) " If a package is being maintained, any release not approved and >> >> supported by the maintainer should use a different package name. >> Then use the Maintainer field as above either to commit to >> supporting the fork yourself or to mark it as unsupported." >> >> >> I would change the final sentance to: "Then put your own name in the >> Maintainer field, to indicate your ongoing support for the package." >> People will figure out that if they want to fork and abandon then they >> can blank the maintainer field, but by default a fork should come with >> support. We don't want to enourage one-shot packages with no support! >> >> But that's a minor thing, and if people want to leave it as it is then >> that's fine. >> >> Thanks >> >> >> Neil >> >> >> >> >> On 6/23/08, Duncan Coutts wrote: >> > If a few more people could read this nice short policy and say "yes that >> > looks fine, I agree" then that would be very helpful. >> > >> > If this is to be something that we put on hackage and expect people to >> > follow then it needs to be *seen* to be supported by people in the >> > community. If we need to act on the policy we don't want to be open to >> > the accusation that the policy was just imposed by Cabal bureaucrats >> > hell-bent on spoiling people's fun but that it actually reflects the >> > general view of the Haskell hacker community. >> > >> > Just because it isn't controversial doesn't mean we don't need your >> > support! :-) >> > >> > Of course if you do have any questions or suggestions then now is a good >> > time to mention them. >> > >> > >> > Duncan >> > >> > >> > On Mon, 2008-06-23 at 10:05 +0100, Ross Paterson wrote: >> > >> > > As a few people have noted, we need to agree a policy in this area. >> > > As I see it, the drivers are: >> > > >> > > * users need to know whether what they're downloading is supported, >> > > and if so by whom. >> > > * maintainers are entitled to control what goes out in their name. >> > > * allocating version numbers for a particular package name should be >> > > the prerogative of the maintainer. >> > > >> > > When something is agreed, I propose to put it on the hackageDB upload >> > > page and expect people to follow it. Here's my first attempt: >> > > >> > > If the Maintainer field names a person or group, the release as >> > > a whole (including packaging) is the named maintainer's approved >> > > release, which they are supporting (at least for some time after >> > > the release). Ideally a maintainer would make that clear by >> > > uploading the release themselves. >> > > >> > > A Maintainer value of "none" indicates that the package is >> > > not supported. >> > > >> > > If a package is being maintained, any release not approved and >> > > supported by the maintainer should use a different package name. >> > > Then use the Maintainer field as above either to commit to >> > > supporting the fork yourself or to mark it as unsupported. >> > >> > >> > _______________________________________________ >> > 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 dons at galois.com Mon Jun 23 19:00:50 2008 From: dons at galois.com (Don Stewart) Date: Mon Jun 23 18:52:28 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: <20080623090559.GA2836@soi.city.ac.uk> References: <20080623090559.GA2836@soi.city.ac.uk> Message-ID: <20080623230050.GJ10144@scytale.galois.com> ross: > As a few people have noted, we need to agree a policy in this area. > As I see it, the drivers are: > > * users need to know whether what they're downloading is supported, > and if so by whom. > * maintainers are entitled to control what goes out in their name. > * allocating version numbers for a particular package name should be > the prerogative of the maintainer. > > When something is agreed, I propose to put it on the hackageDB upload > page and expect people to follow it. Here's my first attempt: > > If the Maintainer field names a person or group, the release as > a whole (including packaging) is the named maintainer's approved > release, which they are supporting (at least for some time after > the release). Ideally a maintainer would make that clear by > uploading the release themselves. > > A Maintainer value of "none" indicates that the package is > not supported. > > If a package is being maintained, any release not approved and > supported by the maintainer should use a different package name. > Then use the Maintainer field as above either to commit to > supporting the fork yourself or to mark it as unsupported. Go for it. From simonpj at microsoft.com Mon Jun 23 20:16:21 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Jun 23 20:07:38 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: <1214257903.15010.1053.camel@localhost> References: <20080623090559.GA2836@soi.city.ac.uk> <1214257903.15010.1053.camel@localhost> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE70CC4FE@EA-EXMSG-C334.europe.corp.microsoft.com> It looks good to me. (I do rather agree that an explicit "unsupported" would be better than blank in the maintainer field.) I'm still hoping that someone will make Hackage able to support user reviews and ratings, so that well-engineered packages get the good feedback they deserve, and stand out from the crowd. Simon | -----Original Message----- | From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On | Behalf Of Duncan Coutts | Sent: 23 June 2008 22:52 | To: Haskell Libraries | Subject: Re: agreeing a policy for maintainers and hackageDB | | If a few more people could read this nice short policy and say "yes that | looks fine, I agree" then that would be very helpful. | | If this is to be something that we put on hackage and expect people to | follow then it needs to be *seen* to be supported by people in the | community. If we need to act on the policy we don't want to be open to | the accusation that the policy was just imposed by Cabal bureaucrats | hell-bent on spoiling people's fun but that it actually reflects the | general view of the Haskell hacker community. | | Just because it isn't controversial doesn't mean we don't need your | support! :-) | | Of course if you do have any questions or suggestions then now is a good | time to mention them. | | Duncan | | On Mon, 2008-06-23 at 10:05 +0100, Ross Paterson wrote: | > As a few people have noted, we need to agree a policy in this area. | > As I see it, the drivers are: | > | > * users need to know whether what they're downloading is supported, | > and if so by whom. | > * maintainers are entitled to control what goes out in their name. | > * allocating version numbers for a particular package name should be | > the prerogative of the maintainer. | > | > When something is agreed, I propose to put it on the hackageDB upload | > page and expect people to follow it. Here's my first attempt: | > | > If the Maintainer field names a person or group, the release as | > a whole (including packaging) is the named maintainer's approved | > release, which they are supporting (at least for some time after | > the release). Ideally a maintainer would make that clear by | > uploading the release themselves. | > | > A Maintainer value of "none" indicates that the package is | > not supported. | > | > If a package is being maintained, any release not approved and | > supported by the maintainer should use a different package name. | > Then use the Maintainer field as above either to commit to | > supporting the fork yourself or to mark it as unsupported. | | | _______________________________________________ | Libraries mailing list | Libraries@haskell.org | http://www.haskell.org/mailman/listinfo/libraries From ross at soi.city.ac.uk Mon Jun 23 20:28:44 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Jun 23 20:20:19 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: <404396ef0806231506r50320a8h4c95af327da657f@mail.gmail.com> References: <20080623090559.GA2836@soi.city.ac.uk> <1214257903.15010.1053.camel@localhost> <404396ef0806231506r50320a8h4c95af327da657f@mail.gmail.com> Message-ID: <20080624002844.GB8531@soi.city.ac.uk> On Mon, Jun 23, 2008 at 11:06:35PM +0100, Neil Mitchell wrote: > 1) I agree with Duncan. I think blank is a much better field name than > "none". What if Mr None wants to maintain a package :-) Another reason > is that its less likely to go wrong, and valid in any language. OK, the package page now flags packages with empty or omitted Maintainer fields (e.g. tagsoup-0.1). The checkPackage function in Cabal still gives a warning on an empty Maintainer field, which is reported by the upload script. I don't know whether that should be changed. (I think unsupported packages rate a bit of disapproval.) > 2) " If a package is being maintained, any release not approved and > supported by the maintainer should use a different package name. > Then use the Maintainer field as above either to commit to > supporting the fork yourself or to mark it as unsupported." > > I would change the final sentance to: "Then put your own name in the > Maintainer field, to indicate your ongoing support for the package." > People will figure out that if they want to fork and abandon then they > can blank the maintainer field, but by default a fork should come with > support. We don't want to enourage one-shot packages with no support! I'd prefer not to leave anything implicit. If we're going to permit unsupported forks, we ought to say what they should look like. (They are, after all, happening now.) From ross at soi.city.ac.uk Mon Jun 23 20:37:14 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Jun 23 20:28:50 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: <20080624002844.GB8531@soi.city.ac.uk> References: <20080623090559.GA2836@soi.city.ac.uk> <1214257903.15010.1053.camel@localhost> <404396ef0806231506r50320a8h4c95af327da657f@mail.gmail.com> <20080624002844.GB8531@soi.city.ac.uk> Message-ID: <20080624003714.GC8531@soi.city.ac.uk> On Tue, Jun 24, 2008 at 01:28:44AM +0100, Ross Paterson wrote: > OK, the package page now flags packages with empty or omitted Maintainer > fields (e.g. tagsoup-0.1). That's easily undone if people decide on a reserved string for unsupported packages. From ndmitchell at gmail.com Mon Jun 23 20:44:45 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Jun 23 20:36:18 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: <20080624002844.GB8531@soi.city.ac.uk> References: <20080623090559.GA2836@soi.city.ac.uk> <1214257903.15010.1053.camel@localhost> <404396ef0806231506r50320a8h4c95af327da657f@mail.gmail.com> <20080624002844.GB8531@soi.city.ac.uk> Message-ID: <404396ef0806231744m58d5c04fo3d82aa5627cef716@mail.gmail.com> Hi > > I would change the final sentance to: "Then put your own name in the > > Maintainer field, to indicate your ongoing support for the package." > > People will figure out that if they want to fork and abandon then they > > can blank the maintainer field, but by default a fork should come with > > support. We don't want to enourage one-shot packages with no support! > > > I'd prefer not to leave anything implicit. If we're going to permit > unsupported forks, we ought to say what they should look like. (They are, > after all, happening now.) Do we want to permit unsupported forks? I am not convinced they are a good idea. As for the maintainer field, thinking about it further, it seems to make sense that no maintainer field is equal to a maintainer field of "" - hence using a blank string for unsupported seems like a bad idea. Therefore an explicit "unsupported" value probably makes more sense. Thanks Neil From bos at serpentine.com Mon Jun 23 23:18:41 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Mon Jun 23 23:10:13 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: <20080623090559.GA2836@soi.city.ac.uk> References: <20080623090559.GA2836@soi.city.ac.uk> Message-ID: On Mon, Jun 23, 2008 at 2:05 AM, Ross Paterson wrote: > When something is agreed, I propose to put it on the hackageDB upload > page and expect people to follow it. Thanks for putting this together. I like it, and I think that any colour will do for the bike shed maintainer field. From antti-juhani at kaijanaho.fi Tue Jun 24 03:30:39 2008 From: antti-juhani at kaijanaho.fi (Antti-Juhani Kaijanaho) Date: Tue Jun 24 03:22:12 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: <1214257903.15010.1053.camel@localhost> References: <20080623090559.GA2836@soi.city.ac.uk> <1214257903.15010.1053.camel@localhost> Message-ID: <20080624073038.GG4901@kukkaseppele.kaijanaho.fi> On Mon, Jun 23, 2008 at 10:51:43PM +0100, Duncan Coutts wrote: > If a few more people could read this nice short policy and say "yes that > looks fine, I agree" then that would be very helpful. Yes, that looks fine, I agree :) I would prefer that a missing Maintainer field were a bug in the metadata instead of being semantically significant. Otherwise there would be no way of distinguishing between "I forgot to add my Maintainer line" and "I am not supporting this". -- Antti-Juhani Kaijanaho, Jyv?skyl?, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/libraries/attachments/20080624/47444c32/attachment.bin From antti-juhani at kaijanaho.fi Tue Jun 24 03:33:56 2008 From: antti-juhani at kaijanaho.fi (Antti-Juhani Kaijanaho) Date: Tue Jun 24 03:25:30 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: <20080624073038.GG4901@kukkaseppele.kaijanaho.fi> References: <20080623090559.GA2836@soi.city.ac.uk> <1214257903.15010.1053.camel@localhost> <20080624073038.GG4901@kukkaseppele.kaijanaho.fi> Message-ID: <20080624073356.GH4901@kukkaseppele.kaijanaho.fi> Also, if putting one's name and address as maintainer is going to imply that the package is supported, we ought to define what minimal level of support is expected. Responds to mails? Accepts/rejects patches in a timely fashion (how fast?)? Answers user handholding requests in a helpful manner? Makes regular releases (how often?)? -- Antti-Juhani Kaijanaho, Jyv?skyl?, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/libraries/attachments/20080624/ff7a571d/attachment-0001.bin From jochem at functor.nl Tue Jun 24 04:51:14 2008 From: jochem at functor.nl (Jochem Berndsen) Date: Tue Jun 24 04:42:43 2008 Subject: Cabal 1.4.0.1 on Debian Stable/GHC 6.6 Message-ID: <1214297474.24685.6.camel@stieltjes.functor.nl> Hi, On a Debian stable (etch) system, I have the following packages installed: jochem@huygens:/tmp/Cabal-1.4.0.1$ dpkg -l | grep ghc ii ghc6 6.6-3 GHC - the Glasgow Haskell Compilation system ii ghc6-prof 6.6-3 Profiling libraries for the Glasgow Haskell ii libghc6-filepath-dev 0.11-2 GHC 6 library for manipulating FilePath's ii libghc6-mtl-dev 1.0-3 Haskell monad transformer library for GHC ii libghc6-network-dev 2.0-3 Haskell network library for GHC jochem@huygens:/tmp/Cabal-1.4.0.1$ ghc-pkg list /usr/lib/ghc-6.6/package.conf: Cabal-1.1.6, (FilePath-0.11), base-2.0, filepath-1.1.0.0, (ghc-6.6), haskell98-1.0, mtl-1.0, network-2.0, parsec-2.0, readline-1.0, regex-base-0.71, regex-compat-0.71, regex-posix-0.71, rts-1.0, stm-2.0, template-haskell-2.0, unix-1.0 jochem@huygens:/tmp/Cabal-1.4.0.1$ I compiled Setup.hs, ran './Setup configure', './Setup build' and finally as root './Setup install'. Then ghc-pkg list gave: jochem@huygens:/tmp/bimap-0.2.2$ ghc-pkg list /usr/lib/ghc-6.6/package.conf: Cabal-1.1.6, Cabal-1.4.0.1, (FilePath-0.11), base-2.0, filepath-1.1.0.0, (ghc-6.6), haskell98-1.0, mtl-1.0, network-2.0, parsec-2.0, readline-1.0, regex-base-0.71, regex-compat-0.71, regex-posix-0.71, rts-1.0, stm-2.0, template-haskell-2.0, unix-1.0 jochem@huygens:/tmp/bimap-0.2.2$ But Cabal seems to be broken; for example, with the bimap package from Hackage: jochem@huygens:/tmp/bimap-0.2.2$ runghc Setup.lhs configure Configuring bimap-0.2.2... Setup.lhs: ghc version >=6.4 is required but the version of /usr/bin/ghc could not be determined. jochem@huygens:/tmp/bimap-0.2.2$ Cabal 1.2.3.0 seems to be working. What am I doing wrong? Or is this an unsupported combination? -- Jochem Berndsen | jochem@functor.nl GPG: 0xE6FABFAB From ashley at semantic.org Tue Jun 24 05:15:19 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Tue Jun 24 05:06:59 2008 Subject: PROPOSAL: Make Applicative a superclass of Monad Message-ID: http://hackage.haskell.org/trac/ghc/ticket/2392 Make Applicative (in Control.Applicative) a superclass of Monad (in Control.Monad). Rename members of Applicative and other functions, to avoid unnecessary duplication. class Functor f => Applicative f where return :: a -> f a ap :: f (a -> b) -> f a -> f b liftA2 :: Applicative f => (a -> b -> c) -> f a -> f b -> f c liftA2 f a b = ap (fmap f a) b (>>) :: (Applicative f) => f a -> f b -> f b (>>) = liftA2 (const id) -- etc. class Applicative m => Monad m where (>>=) :: m a -> (a -> m b) -> m b fail :: String -> m a fail s = error s I do not have a patch for this change, as it involves mucking around with GHC.Base, and I strongly suspect also fiddling with the GHC source. I'd like to know if it's feasible first. Discussion period: a month? -- Ashley Yakeley From lemming at henning-thielemann.de Tue Jun 24 05:24:08 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Jun 24 05:16:01 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE70CC4FE@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20080623090559.GA2836@soi.city.ac.uk> <1214257903.15010.1053.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C32AE70CC4FE@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: On Tue, 24 Jun 2008, Simon Peyton-Jones wrote: > I'm still hoping that someone will make Hackage able to support user > reviews and ratings, so that well-engineered packages get the good > feedback they deserve, and stand out from the crowd. As Chris Kuklewicz explains in the other thread "package spam", an unmaintained package is often not generated by someone who uploads a new version where only the Cabal field Maintainer is removed or changed to the empty string. Actually a package most oftenly becomes unmaintained by being not updated for a long time. Thus I think the time of the last release, the highest compiler version it is tested with and so on may be sorting criteria for finding out the most up-to-date packages. If nevertheless an unmaintained flag should be managed, this should be part of HackageDB (like user reviews), not part of Cabal. But then I wonder who shall decide whether a package is maintained or not. Sometimes users are afraid that a package is unmaintained because there was no new release for half a year, although patches are constantly committed to a darcs repository. From ross at soi.city.ac.uk Tue Jun 24 05:26:44 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Jun 24 05:18:19 2008 Subject: PROPOSAL: Make Applicative a superclass of Monad In-Reply-To: References: Message-ID: <20080624092644.GA8923@soi.city.ac.uk> On Tue, Jun 24, 2008 at 02:15:19AM -0700, Ashley Yakeley wrote: > http://hackage.haskell.org/trac/ghc/ticket/2392 > > Make Applicative (in Control.Applicative) a superclass of Monad (in > Control.Monad). Rename members of Applicative and other functions, to > avoid unnecessary duplication. The big problem with this is that it would break compatibility with Haskell 98, and any existing program that defines a Monad instance. From bulat.ziganshin at gmail.com Tue Jun 24 05:30:14 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Jun 24 05:23:28 2008 Subject: PROPOSAL: Make Applicative a superclass of Monad In-Reply-To: References: Message-ID: <814962006.20080624133014@gmail.com> Hello Ashley, Tuesday, June 24, 2008, 1:15:19 PM, you wrote: > Make Applicative (in Control.Applicative) a superclass of Monad (in it will break H98 compatibility - some code written in H98 will be impossible to compile with such library. since GHC is (among other features) provides full H98 compatibility, we can't make such change well, at least i expect such answer from GHC HQ :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ross at soi.city.ac.uk Tue Jun 24 05:47:50 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Jun 24 05:39:25 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: References: <20080623090559.GA2836@soi.city.ac.uk> <1214257903.15010.1053.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C32AE70CC4FE@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20080624094750.GB8923@soi.city.ac.uk> On Tue, Jun 24, 2008 at 11:24:08AM +0200, Henning Thielemann wrote: > As Chris Kuklewicz explains in the other thread "package spam", an > unmaintained package is often not generated by someone who uploads a new > version where only the Cabal field Maintainer is removed or changed to > the empty string. Actually a package most oftenly becomes unmaintained by > being not updated for a long time. Thus I think the time of the last > release, the highest compiler version it is tested with and so on may be > sorting criteria for finding out the most up-to-date packages. > If nevertheless an unmaintained flag should be managed, this should be > part of HackageDB (like user reviews), not part of Cabal. But then I > wonder who shall decide whether a package is maintained or not. Sometimes > users are afraid that a package is unmaintained because there was no new > release for half a year, although patches are constantly committed to a > darcs repository. All that other information will be useful in building the complete picture. Breaking changes to the core libraries are also helpful in weeding out unmaintained packages :-). The maintainer field is an additional piece of information, describing the situation at the time of the release. There are two kinds of uploads that are happening now, but are difficult to distinguish from normal releases: * museum pieces: a package that hasn't been touched for years is updated to use Cabal and the latest libraries and uploaded. * can't wait for the maintainer: someone takes the current state of the darcs repository, possibly makes a few fixes, and uploads that. If these are to be allowed, users (and future filtering schemes) really need to be able to identify them. From duncan.coutts at worc.ox.ac.uk Tue Jun 24 05:57:40 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jun 24 05:44:24 2008 Subject: Cabal 1.4.0.1 on Debian Stable/GHC 6.6 In-Reply-To: <1214297474.24685.6.camel@stieltjes.functor.nl> References: <1214297474.24685.6.camel@stieltjes.functor.nl> Message-ID: <1214301460.15010.1078.camel@localhost> On Tue, 2008-06-24 at 10:51 +0200, Jochem Berndsen wrote: > Hi, > > On a Debian stable (etch) system, I have the following packages > installed: > > jochem@huygens:/tmp/Cabal-1.4.0.1$ dpkg -l | grep ghc > ii ghc6 6.6-3 Ok, so that's actually ghc-6.6 not 6.6.1 > jochem@huygens:/tmp/bimap-0.2.2$ runghc Setup.lhs configure > Configuring bimap-0.2.2... > Setup.lhs: ghc version >=6.4 is required but the version of /usr/bin/ghc > could > not be determined. > jochem@huygens:/tmp/bimap-0.2.2$ > Cabal 1.2.3.0 seems to be working. What am I doing wrong? Or is this an > unsupported combination? It's an untested combination. I checked it with 6.6.1 but not 6.6. It is supposed to work (indeed it's supposed to work with 6.4) so we should figure out what's going wrong. Can you : $ runghc Setup.lhs configure -v3 It should give more detail about how Cabal called ghc and what string value it returned. Duncan From jochem at functor.nl Tue Jun 24 06:07:03 2008 From: jochem at functor.nl (Jochem Berndsen) Date: Tue Jun 24 05:58:47 2008 Subject: Cabal 1.4.0.1 on Debian Stable/GHC 6.6 In-Reply-To: <1214301460.15010.1078.camel@localhost> References: <1214297474.24685.6.camel@stieltjes.functor.nl> <1214301460.15010.1078.camel@localhost> Message-ID: <1214302023.24685.12.camel@stieltjes.functor.nl> On Tue, 2008-06-24 at 10:57 +0100, Duncan Coutts wrote: > > jochem@huygens:/tmp/bimap-0.2.2$ runghc Setup.lhs configure > > Configuring bimap-0.2.2... > > Setup.lhs: ghc version >=6.4 is required but the version of /usr/bin/ghc > > could > > not be determined. > > jochem@huygens:/tmp/bimap-0.2.2$ > > > Cabal 1.2.3.0 seems to be working. What am I doing wrong? Or is this an > > unsupported combination? > > It's an untested combination. I checked it with 6.6.1 but not 6.6. > > It is supposed to work (indeed it's supposed to work with 6.4) so we > should figure out what's going wrong. > > Can you : > $ runghc Setup.lhs configure -v3 jochem@huygens:/tmp/bimap-0.2.2$ runghc Setup.lhs configure -v3 Configuring bimap-0.2.2... Creating dist (and its parents) searching for ghc in path. found ghc at /usr/bin/ghc ("/usr/bin/ghc",["--numeric-version"]) Warning: cannot determine version of /usr/bin/ghc : "" Setup.lhs: ghc version >=6.4 is required but the version of /usr/bin/ghc could not be determined. jochem@huygens:/tmp/bimap-0.2.2$ ghc --numeric-version 6.6 jochem@huygens:/tmp/bimap-0.2.2$ ghc in my sid (debian unstable) chroot gave "6.8.2". Maybe Cabal 1.4 doesn't like versions of the form x.y, only of the form x.y.z (wild speculation)? By the way, compiling the Setup.lhs-file of bimap and running it does work: jochem@huygens:/tmp/bimap-0.2.2$ ghc --make Setup.lhs -o Setup [1 of 1] Compiling Main ( Setup.lhs, Setup.o ) Linking Setup ... jochem@huygens:/tmp/bimap-0.2.2$ ./Setup configure Configuring bimap-0.2.2... jochem@huygens:/tmp/bimap-0.2.2$ -- Jochem Berndsen | jochem@functor.nl GPG: 0xE6FABFAB From Malcolm.Wallace at cs.york.ac.uk Tue Jun 24 06:14:41 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Jun 24 06:06:43 2008 Subject: PROPOSAL: Make Applicative a superclass of Monad In-Reply-To: References: Message-ID: <20080624111441.46f4112a.Malcolm.Wallace@cs.york.ac.uk> Ashley Yakeley wrote: > Make Applicative (in Control.Applicative) a superclass of Monad (in > Control.Monad). I'm strongly against. Some datatypes have several different possible implementations of Applicative, for instance, they may be either lazy or strict. The PolyParse library relies crucially on the fact that the Monad and Applicative instances for the Parser type have different strictness behaviours. I worry that if Applicative were to become a superclass of Monad, this way of partitioning my API into lazy and strict portions may no longer be possible, or least, a good deal less convenient. Regards, Malcolm Footnote. PolyParse does not currently use the real Applicative class, but it probably ought to. From lemming at henning-thielemann.de Tue Jun 24 06:43:35 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Jun 24 06:35:08 2008 Subject: PROPOSAL: Make Applicative a superclass of Monad In-Reply-To: <20080624111441.46f4112a.Malcolm.Wallace@cs.york.ac.uk> References: <20080624111441.46f4112a.Malcolm.Wallace@cs.york.ac.uk> Message-ID: On Tue, 24 Jun 2008, Malcolm Wallace wrote: > Ashley Yakeley wrote: > >> Make Applicative (in Control.Applicative) a superclass of Monad (in >> Control.Monad). > > I'm strongly against. > > Some datatypes have several different possible implementations of > Applicative, for instance, they may be either lazy or strict. The > PolyParse library relies crucially on the fact that the Monad and > Applicative instances for the Parser type have different strictness > behaviours. > > I worry that if Applicative were to become a superclass of Monad, this > way of partitioning my API into lazy and strict portions may no longer > be possible, or least, a good deal less convenient. Although I also see no compatible way to make Applicative a superclass of Monad, I think it should be so. Intuitively it is a superclass and it would surprise me if a library has inconsistent instances of Applicative and Monad. So I count your example as argument _for_ making Applicative a superclass of Monad in order to reduce the risk of surprises for the library user. From duncan.coutts at worc.ox.ac.uk Tue Jun 24 06:53:04 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jun 24 06:39:40 2008 Subject: Cabal 1.4.0.1 on Debian Stable/GHC 6.6 In-Reply-To: <1214302023.24685.12.camel@stieltjes.functor.nl> References: <1214297474.24685.6.camel@stieltjes.functor.nl> <1214301460.15010.1078.camel@localhost> <1214302023.24685.12.camel@stieltjes.functor.nl> Message-ID: <1214304784.15010.1100.camel@localhost> On Tue, 2008-06-24 at 12:07 +0200, Jochem Berndsen wrote: > jochem@huygens:/tmp/bimap-0.2.2$ runghc Setup.lhs configure -v3 > Configuring bimap-0.2.2... > Creating dist (and its parents) > searching for ghc in path. > found ghc at /usr/bin/ghc > ("/usr/bin/ghc",["--numeric-version"]) > Warning: cannot determine version of /usr/bin/ghc : > "" > Setup.lhs: ghc version >=6.4 is required but the version of /usr/bin/ghc > could > not be determined. > jochem@huygens:/tmp/bimap-0.2.2$ ghc --numeric-version > 6.6 > jochem@huygens:/tmp/bimap-0.2.2$ I cannot reproduce this. I tried on the community server which is debian 4.0 (which I think is etch right?). It was using ghc-6.6. I tried with Cabal-1.4.0.1 and bimap from hackage. > ghc in my sid (debian unstable) chroot gave "6.8.2". Maybe Cabal 1.4 > doesn't like versions of the form x.y, only of the form x.y.z (wild > speculation)? No, that should be fine. It's parsing a Version so that can be any sequence of digits separated by dots. > By the way, compiling the Setup.lhs-file of bimap and running it does > work: > > jochem@huygens:/tmp/bimap-0.2.2$ ghc --make Setup.lhs -o Setup > [1 of 1] Compiling Main ( Setup.lhs, Setup.o ) > Linking Setup ... > jochem@huygens:/tmp/bimap-0.2.2$ ./Setup configure > Configuring bimap-0.2.2... > jochem@huygens:/tmp/bimap-0.2.2$ That's pretty weird. Are you sure ghc and runghc are the same version? Duncan From jochem at functor.nl Tue Jun 24 07:33:20 2008 From: jochem at functor.nl (Jochem Berndsen) Date: Tue Jun 24 07:24:47 2008 Subject: Cabal 1.4.0.1 on Debian Stable/GHC 6.6 In-Reply-To: <1214304784.15010.1100.camel@localhost> References: <1214297474.24685.6.camel@stieltjes.functor.nl> <1214301460.15010.1078.camel@localhost> <1214302023.24685.12.camel@stieltjes.functor.nl> <1214304784.15010.1100.camel@localhost> Message-ID: <1214307200.24685.22.camel@stieltjes.functor.nl> On Tue, 2008-06-24 at 11:53 +0100, Duncan Coutts wrote: > I cannot reproduce this. I tried on the community server which is debian > 4.0 (which I think is etch right?). It was using ghc-6.6. I tried with > Cabal-1.4.0.1 and bimap from hackage. 4.0 is etch, indeed. > > ghc in my sid (debian unstable) chroot gave "6.8.2". Maybe Cabal 1.4 > > doesn't like versions of the form x.y, only of the form x.y.z (wild > > speculation)? > > No, that should be fine. It's parsing a Version so that can be any > sequence of digits separated by dots. > > > By the way, compiling the Setup.lhs-file of bimap and running it does > > work: > > > > jochem@huygens:/tmp/bimap-0.2.2$ ghc --make Setup.lhs -o Setup > > [1 of 1] Compiling Main ( Setup.lhs, Setup.o ) > > Linking Setup ... > > jochem@huygens:/tmp/bimap-0.2.2$ ./Setup configure > > Configuring bimap-0.2.2... > > jochem@huygens:/tmp/bimap-0.2.2$ > > That's pretty weird. Are you sure ghc and runghc are the same version? Yes, the only version I ever installed on that machine is ghc 6.6 from the Debian archives. Also, there exists a symlink /usr/bin/runghc -> /etc/alternatives/runghc -> /usr/lib/ghc-6.6/bin/runghc. I can't reproduce the problem on my laptop (debian etch) as well. Adding some debug output in Cabal seems to reveal the problem: waitForProcess, when called from rawSystemStdout, throws an exception: waitForProcess: does not exist (No child processes) Reinstalling the ghc6 package, reinstalling filepath and cabal did not fix this problem. Any idea? I guess it is outside the realm of Cabal. -- Jochem Berndsen | jochem@functor.nl GPG: 0xE6FABFAB From Christian.Maeder at dfki.de Tue Jun 24 07:43:08 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Jun 24 07:34:38 2008 Subject: PROPOSAL: Make Applicative a superclass of Monad In-Reply-To: <20080624092644.GA8923@soi.city.ac.uk> References: <20080624092644.GA8923@soi.city.ac.uk> Message-ID: <4860DDCC.509@dfki.de> Could someone explain why it breaks H98 compatibility? Control.Applicative alone is at least marked "portable". Thanks Christian Ross Paterson wrote: > On Tue, Jun 24, 2008 at 02:15:19AM -0700, Ashley Yakeley wrote: >> http://hackage.haskell.org/trac/ghc/ticket/2392 >> >> Make Applicative (in Control.Applicative) a superclass of Monad (in >> Control.Monad). Rename members of Applicative and other functions, to >> avoid unnecessary duplication. > > The big problem with this is that it would break compatibility with > Haskell 98, and any existing program that defines a Monad instance. From jochem at functor.nl Tue Jun 24 07:46:29 2008 From: jochem at functor.nl (Jochem Berndsen) Date: Tue Jun 24 07:37:58 2008 Subject: Cabal 1.4.0.1 on Debian Stable/GHC 6.6 In-Reply-To: <1214307200.24685.22.camel@stieltjes.functor.nl> References: <1214297474.24685.6.camel@stieltjes.functor.nl> <1214301460.15010.1078.camel@localhost> <1214302023.24685.12.camel@stieltjes.functor.nl> <1214304784.15010.1100.camel@localhost> <1214307200.24685.22.camel@stieltjes.functor.nl> Message-ID: <1214307989.24685.29.camel@stieltjes.functor.nl> On Tue, 2008-06-24 at 13:33 +0200, Jochem Berndsen wrote: > I can't reproduce the problem on my laptop (debian etch) as well. > Adding some debug output in Cabal seems to reveal the problem: > waitForProcess, when called from rawSystemStdout, throws an exception: > > waitForProcess: does not exist (No child processes) > > Reinstalling the ghc6 package, reinstalling filepath and cabal did not > fix this problem. Any idea? I guess it is outside the realm of Cabal. This seems to be an instance of a bug in GHC 6.6, #945, see http://hackage.haskell.org/trac/ghc/ticket/945 I'm sorry to have bothered you :) by the way, a `catch` around waitForProcess to ignore all exceptions makes Cabal 1.4.0.1 work for me (as a workaround; this probably will cause havoc in the future. I've been warned) :) -- Jochem Berndsen | jochem@functor.nl GPG: 0xE6FABFAB From ross at soi.city.ac.uk Tue Jun 24 07:48:38 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Jun 24 07:40:14 2008 Subject: PROPOSAL: Make Applicative a superclass of Monad In-Reply-To: <4860DDCC.509@dfki.de> References: <20080624092644.GA8923@soi.city.ac.uk> <4860DDCC.509@dfki.de> Message-ID: <20080624114838.GA676@soi.city.ac.uk> On Tue, Jun 24, 2008 at 01:43:08PM +0200, Christian Maeder wrote: > Could someone explain why it breaks H98 compatibility? > Control.Applicative alone is at least marked "portable". The following Haskell 98 code would be rejected: newtype Id a = Id a instance Monad Id where return = Id Id x >>= f = f x From lemming at henning-thielemann.de Tue Jun 24 07:50:28 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Jun 24 07:42:03 2008 Subject: PROPOSAL: Make Applicative a superclass of Monad In-Reply-To: <4860DDCC.509@dfki.de> References: <20080624092644.GA8923@soi.city.ac.uk> <4860DDCC.509@dfki.de> Message-ID: On Tue, 24 Jun 2008, Christian Maeder wrote: > Could someone explain why it breaks H98 compatibility? Control.Applicative > alone is at least marked "portable". Because existing Monad instances in user code would become invalid. From igloo at earth.li Tue Jun 24 07:51:59 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Jun 24 07:43:31 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: <1214257903.15010.1053.camel@localhost> References: <20080623090559.GA2836@soi.city.ac.uk> <1214257903.15010.1053.camel@localhost> Message-ID: <20080624115159.GA17344@matrix.chaos.earth.li> On Mon, Jun 23, 2008 at 10:51:43PM +0100, Duncan Coutts wrote: > > Of course if you do have any questions or suggestions then now is a good > time to mention them. I think we should also say what "maintainer: libraries@haskell.org" means: how we decide which packages should use that as maintainer, who can do uploads of them, etc. Thanks Ian From igloo at earth.li Tue Jun 24 07:54:08 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Jun 24 07:45:40 2008 Subject: PROPOSAL: Make Applicative a superclass of Monad In-Reply-To: <4860DDCC.509@dfki.de> References: <20080624092644.GA8923@soi.city.ac.uk> <4860DDCC.509@dfki.de> Message-ID: <20080624115407.GB17344@matrix.chaos.earth.li> On Tue, Jun 24, 2008 at 01:43:08PM +0200, Christian Maeder wrote: > Could someone explain why it breaks H98 compatibility? > Control.Applicative alone is at least marked "portable". This Haskell98 module no longer works: module Foo where data Foo a = Foo instance Monad Foo where return _ = Foo Thanks Ian From igloo at earth.li Tue Jun 24 07:55:15 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Jun 24 07:46:47 2008 Subject: PROPOSAL: Make Applicative a superclass of Monad In-Reply-To: References: Message-ID: <20080624115515.GC17344@matrix.chaos.earth.li> On Tue, Jun 24, 2008 at 02:15:19AM -0700, Ashley Yakeley wrote: > http://hackage.haskell.org/trac/ghc/ticket/2392 > > Make Applicative (in Control.Applicative) a superclass of Monad (in > Control.Monad). I agree with what other people have said about H98 compatibility. I think you would be better off proposing this for Haskell'. Thanks Ian From ross at soi.city.ac.uk Tue Jun 24 08:08:33 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Jun 24 08:00:07 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: <20080624115159.GA17344@matrix.chaos.earth.li> References: <20080623090559.GA2836@soi.city.ac.uk> <1214257903.15010.1053.camel@localhost> <20080624115159.GA17344@matrix.chaos.earth.li> Message-ID: <20080624120832.GB676@soi.city.ac.uk> On Tue, Jun 24, 2008 at 12:51:59PM +0100, Ian Lynagh wrote: > On Mon, Jun 23, 2008 at 10:51:43PM +0100, Duncan Coutts wrote: > > > > Of course if you do have any questions or suggestions then now is a good > > time to mention them. > > I think we should also say what "maintainer: libraries@haskell.org" > means: how we decide which packages should use that as maintainer, who > can do uploads of them, etc. I think it means that interface changes have to go through the library submissions process. Currently releases of them are created as part of GHC releases, but I guess you want to change that for some of them at some point in the future. From benjovi at gmx.net Tue Jun 24 08:11:34 2008 From: benjovi at gmx.net (Benedikt Huber) Date: Tue Jun 24 08:03:10 2008 Subject: [Ticket #2393] Text.PrettyPrint.HughesPJ: Bug fixes, performance improvement References: <755307ED-284E-4DBF-AF8E-2BEEAD64248D@gmail.com> Message-ID: <1F6084B0-7E94-461D-AA21-B6FEFC089852@gmx.net> Hello, I'd like to propose bugfixes, documentation fixes and a performance improvement for Text.PrettyPrint.HughesPJ. The changes shouldn't effect the expected behaviour of the PP library. I've written a QuickCheck test suite for the pretty printer (to test the improvement), and found two bugs and some misconceptions/ ambiguities in the documentation. Additionally, there is a microbenchmark for the suggested improvement. Both are available at http://code.haskell.org/~bhuber/Text/ PrettyPrint/. Note that the QuickCheck tests need access to all top- level names in HughesPJ (i.e. ignore the export list). In summary, I propose to * fix a bug in fillNB and one in fillNB/sepNB * correct documentation on laws and invariants. * add more efficient implementations of vcat,hsep,hcat More specifically: (1) Bugfix fillNB: Additional case for fillNB Empty (Empty : ys) (2) Bugfix [f](cat|sep): do not allow overlapping ($$) in vertical composition (3) Lazy implementations of vcat,hcat and hsep (4) Law isn't always true (5) Invariant 5 should be made stronger (6) Change the comment about negative indentation The details follow below (maybe a little long). best regards, benedikt = = = = = = = = ======================================================================== == Details (Long) == Bug Fixes -------------------------------------- (1) Bugfix fillNB Law states that > sep (ps++[empty]++qs) = sep (ps ++ qs) > ...ditto hsep, hcat, vcat, fill... In the current implementation, this fails for the paragraph fill variants. > render' $ fill True [ text "c", text "c",empty, text "c", text "b"] > where render' = renderStyle (Style PageMode 7 1.4) >> c c c >> b The reason is a missing test for Empty in fillNB 2) Bugfix: overlap and f?(cat|sep) The specification for cat/sep: * oneLiner (hcat/hsep ps) `union` vcat ps [*] But currently cat, sep, fcat and fsep attempt to overlap the second line with the first one, i.e. they use `foldr ($$) empty ps' instead of `foldr ($+$) empty ps' [*]. I assume this is a mistake. This bug can lead to situations, where the line in the right argument of Union is actually longer: > prettyDoc$ cat [ text "a", nest 2 ( text "b") ] >> text "a"; union >> (text "b"; empty) >> (nilabove; nest 1; text "b"; empty) > renderStyle (Style PageMode 1 1) $ cat [ text "a", nest 2 ( text "b") ] >> "a b" In the implementation, we call `nilAbove False' instead of `nilAbove True' (see patch). Performance Improvements -------------------------------------- 3) Improving the space/time performance of vcat, hsep, hcat vcat (hsep,cat) is implemented in an unneccessarily strict way. We only get some output after all of vcat's arguments are evaluated and checked against being Empty. This can be improved by only checking the right argument of foldr against being Empty, and then applying an Empty-filter on the resulting Doc. Space improvement is obvious. The microbenchmark (code.haskell.org/~bhuber/Text/PrettyPrint/ HughesPJPerfCheck.hs) suggests that the improvements in time are remarkable too. Documentation fixes -------------------------------------- The QuickCheck tests revealed that 4) Law isn't always true text "" <> x = x, if x non-empty only holds if x does not start with nest (obviously, because of law ). 5) The invariant 5 should be extended: A @NoDoc@ may only appear on the first line of the left argument of an union. Therefore, the right argument of an union can never be equivalent to the empty set. because this assumption is used when rendering. 6) Change the comment about negative indentation In the source code we have: -- (spaces n) generates a list of n spaces -- It should never be called with 'n' < 0, but that can happen for reasons I don't understand If we compose a <> b, and the first line of b is deeply nested, but other lines of b are not, then, because <> eats the nest, the pretty printer will try to layout some of b's lines with negative indentation: doc |0123345 ------------------ d1 |a d2 | b |c d1<>d2 |ab c| Here is the reason why this is rather unavoidable: In John Hughes paper, there is a line stating that "composing layouts does not change the layouts being composed". Another one states that "<> should eat up nests" But this leads to negative indentation - imho a user error. == End == -------------- next part -------------- A non-text attachment was scrubbed... Name: HughesPJ.patch Type: application/octet-stream Size: 5178 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20080624/2c814c94/HughesPJ-0001.obj -------------- next part -------------- From Christian.Maeder at dfki.de Tue Jun 24 08:27:21 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Jun 24 08:18:49 2008 Subject: PROPOSAL: Make Applicative a superclass of Monad In-Reply-To: References: <20080624092644.GA8923@soi.city.ac.uk> <4860DDCC.509@dfki.de> Message-ID: <4860E829.7040005@dfki.de> Henning Thielemann wrote: > > On Tue, 24 Jun 2008, Christian Maeder wrote: > >> Could someone explain why it breaks H98 compatibility? >> Control.Applicative alone is at least marked "portable". > > Because existing Monad instances in user code would become invalid. Ok, I was thinking in terms of language features (not in terms of backward compatibility of the Standard Library). Christian From simonpj at microsoft.com Tue Jun 24 08:39:48 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Jun 24 08:31:26 2008 Subject: [Ticket #2393] Text.PrettyPrint.HughesPJ: Bug fixes, performance improvement In-Reply-To: <1F6084B0-7E94-461D-AA21-B6FEFC089852@gmx.net> References: <755307ED-284E-4DBF-AF8E-2BEEAD64248D@gmail.com> <1F6084B0-7E94-461D-AA21-B6FEFC089852@gmx.net> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE70CC842@EA-EXMSG-C334.europe.corp.microsoft.com> Thank you for doing this Benedict. I've added your more detailed comments to ticket #2393 so that they are preserved. Ian: would you like to apply? I'm not sure how to integrate the QuickCheck tests, but I bet you know. Benedict: while you are in the area, would you like to take a swing at http://hackage.haskell.org/trac/ghc/ticket/1337, and 1176? Simon | -----Original Message----- | From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Benedikt Huber | Sent: 24 June 2008 13:12 | To: libraries@haskell.org | Subject: [Ticket #2393] Text.PrettyPrint.HughesPJ: Bug fixes, performance improvement | | Hello, | | I'd like to propose bugfixes, documentation fixes and a performance | improvement for Text.PrettyPrint.HughesPJ. The changes shouldn't | effect the expected behaviour of the PP library. | | I've written a QuickCheck test suite for the pretty printer (to test | the improvement), and found two bugs and some misconceptions/ | ambiguities in the documentation. Additionally, there is a | microbenchmark for the suggested improvement. | Both are available at http://code.haskell.org/~bhuber/Text/ | PrettyPrint/. Note that the QuickCheck tests need access to all top- | level names in HughesPJ (i.e. ignore the export list). | | In summary, I propose to | * fix a bug in fillNB and one in fillNB/sepNB | * correct documentation on laws and invariants. | * add more efficient implementations of vcat,hsep,hcat | | More specifically: | | (1) Bugfix fillNB: Additional case for fillNB Empty (Empty : ys) | | (2) Bugfix [f](cat|sep): do not allow overlapping ($$) in vertical | composition | | (3) Lazy implementations of vcat,hcat and hsep | | (4) Law isn't always true | | (5) Invariant 5 should be made stronger | | (6) Change the comment about negative indentation | From isaacdupree at charter.net Tue Jun 24 09:42:48 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Tue Jun 24 09:34:30 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: <404396ef0806231744m58d5c04fo3d82aa5627cef716@mail.gmail.com> References: <20080623090559.GA2836@soi.city.ac.uk> <1214257903.15010.1053.camel@localhost> <404396ef0806231506r50320a8h4c95af327da657f@mail.gmail.com> <20080624002844.GB8531@soi.city.ac.uk> <404396ef0806231744m58d5c04fo3d82aa5627cef716@mail.gmail.com> Message-ID: <4860F9D8.5060800@charter.net> Neil Mitchell wrote: > Hi > >> > I would change the final sentance to: "Then put your own name in the >> > Maintainer field, to indicate your ongoing support for the package." >> > People will figure out that if they want to fork and abandon then they >> > can blank the maintainer field, but by default a fork should come with >> > support. We don't want to enourage one-shot packages with no support! >> >> >> I'd prefer not to leave anything implicit. If we're going to permit >> unsupported forks, we ought to say what they should look like. (They are, >> after all, happening now.) > > Do we want to permit unsupported forks? I am not convinced they are a good idea. what do we do if a package becomes unsupported? delete it? Or are you just concerned about it if they're *forks* that no one ever intended to support (rather than a maintainer of a package leaving after a while)? anyway, here's the conflict between hackage as a repository of anything Haskell that someone might use/start maintaining, or hackage as a collection of stuff that's generally supposed to work "out-of-the-box" to some extent(cabal-install). Does cabal-install make it easy to install something that's not in hackage.haskell.org (but is somewhere else on the web, where you know the URL)? -Isaac From isaacdupree at charter.net Tue Jun 24 09:51:30 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Tue Jun 24 09:43:11 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: <20080624073356.GH4901@kukkaseppele.kaijanaho.fi> References: <20080623090559.GA2836@soi.city.ac.uk> <1214257903.15010.1053.camel@localhost> <20080624073038.GG4901@kukkaseppele.kaijanaho.fi> <20080624073356.GH4901@kukkaseppele.kaijanaho.fi> Message-ID: <4860FBE2.7050207@charter.net> Antti-Juhani Kaijanaho wrote: > Also, if putting one's name and address as maintainer is going to imply > that the package is supported, we ought to define what minimal level > of support is expected. Responds to mails? Accepts/rejects patches in > a timely fashion (how fast?)? Answers user handholding requests in a > helpful manner? Makes regular releases (how often?)? well, assuming maintainer=libraries@h.o is "supported", we clearly shouldn't expect anything more than we expect ourselves to do. Which is in practice something like: - responds to mails (at least usually) - can easily ignore patches, due both to the library submissions proposal policy (submitters are told to run off to GHC Trac and learn that too), and then once that's done, by accident (so then they have to poke someone, but because of the policy, that now generally gets a definite response). If process is followed, timeframe is a few weeks. - regular releases? I have no idea, except I think it's probably at least once a year because of major GHC versions (at least for boot-packages). -Isaac From ndmitchell at gmail.com Tue Jun 24 09:52:33 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Jun 24 09:44:08 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: <4860F9D8.5060800@charter.net> References: <20080623090559.GA2836@soi.city.ac.uk> <1214257903.15010.1053.camel@localhost> <404396ef0806231506r50320a8h4c95af327da657f@mail.gmail.com> <20080624002844.GB8531@soi.city.ac.uk> <404396ef0806231744m58d5c04fo3d82aa5627cef716@mail.gmail.com> <4860F9D8.5060800@charter.net> Message-ID: <404396ef0806240652g5dab387dvaacb03ea763d0d2b@mail.gmail.com> Hi > what do we do if a package becomes unsupported? delete it? Or are you > just concerned about it if they're *forks* that no one ever intended to > support (rather than a maintainer of a package leaving after a while)? The second. Packages will become unsupported, packages will be forked, but being forked and unsupported simultaneously is probably bad. Thanks Neil From isaacdupree at charter.net Tue Jun 24 09:57:39 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Tue Jun 24 09:49:11 2008 Subject: PROPOSAL: Make Applicative a superclass of Monad In-Reply-To: <814962006.20080624133014@gmail.com> References: <814962006.20080624133014@gmail.com> Message-ID: <4860FD53.3080002@charter.net> Bulat Ziganshin wrote: > Hello Ashley, > > Tuesday, June 24, 2008, 1:15:19 PM, you wrote: > >> Make Applicative (in Control.Applicative) a superclass of Monad (in > > it will break H98 compatibility - some code written in H98 will be > impossible to compile with such library. since GHC is (among other > features) provides full H98 compatibility, we can't make such change Is there any practical way we can make this change while still making it possible to compile Haskell98 programs at all? It seems that even with a compiler flag, it will be difficult to do with current haskell implementations (at the very least, a different Monad class would have to be exported from haskell98 modules than from... modern modules.) From isaacdupree at charter.net Tue Jun 24 10:01:45 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Tue Jun 24 09:53:16 2008 Subject: PROPOSAL: Make Applicative a superclass of Monad In-Reply-To: References: Message-ID: <4860FE49.1040609@charter.net> Ashley Yakeley wrote: > class Applicative m => Monad m where > (>>=) :: m a -> (a -> m b) -> m b > fail :: String -> m a > fail s = error s I'd personally like (join :: m (m a) -> m a) to also be in Monad, with default definitions between (>>=) and join, because some monads are more naturally defined by one than the other. (just while we're (not) making breaking changes, and because the default for (>>=) would have to depend on fmap, I though I'd mention it :-) -Isaac From allbery at ece.cmu.edu Tue Jun 24 10:28:21 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Jun 24 10:19:53 2008 Subject: PROPOSAL: Make Applicative a superclass of Monad In-Reply-To: <4860FD53.3080002@charter.net> References: <814962006.20080624133014@gmail.com> <4860FD53.3080002@charter.net> Message-ID: <2B81919C-32AB-4F77-8A1F-87C8D6A849EC@ece.cmu.edu> On Jun 24, 2008, at 09:57 , Isaac Dupree wrote: > Bulat Ziganshin wrote: >> Hello Ashley, >> Tuesday, June 24, 2008, 1:15:19 PM, you wrote: >>> Make Applicative (in Control.Applicative) a superclass of Monad (in >> it will break H98 compatibility - some code written in H98 will be >> impossible to compile with such library. since GHC is (among other >> features) provides full H98 compatibility, we can't make such change > > Is there any practical way we can make this change while still > making it possible to compile Haskell98 programs at all? It seems > that even with a compiler flag, it will be difficult to do with Problem there is that Monad is exported by Prelude. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From bulat.ziganshin at gmail.com Tue Jun 24 10:29:03 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Jun 24 10:22:21 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: <4860F9D8.5060800@charter.net> References: <20080623090559.GA2836@soi.city.ac.uk> <1214257903.15010.1053.camel@localhost> <404396ef0806231506r50320a8h4c95af327da657f@mail.gmail.com> <20080624002844.GB8531@soi.city.ac.uk> <404396ef0806231744m58d5c04fo3d82aa5627cef716@mail.gmail.com> <4860F9D8.5060800@charter.net> Message-ID: <288267141.20080624182903@gmail.com> Hello Isaac, Tuesday, June 24, 2008, 5:42:48 PM, you wrote: >> Do we want to permit unsupported forks? I am not convinced they are a good idea. imho, we are going too deep into this topic. there are even proposals to force developers to answer emails :) We have AUTHORS field which should list everyone contributed to the package just for copyrighting purposes. and we have MAINTAINER field for the person(s) which are ready to accept patches, feature requests and ask dumb user questions. that's all if one uploading package know person which maintains package in above-mentioned meaning, he declare that person in .cabal file. if noone is expected to support the package, it may be mentioned too non-maintainers shouldn't upload new versions of maintained packages without written ;) maintainer permission. well, as far as maintainer answers their letters it should be ok to fork existing maintained library Foo as SuperFoo and leave it unmaintained - sometimes we write just for fun (things useful for other haskellers) i think that Hackage should be database of ALL packages, and other ways should be used to distinguish between better and worse ones (such as download count, maintainer field, version, last update time...) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jeremy at n-heptane.com Tue Jun 24 13:59:12 2008 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Tue Jun 24 13:48:32 2008 Subject: Package spam :-) In-Reply-To: <1214257218.15010.1041.camel@localhost> References: <4858F398.20708@iee.org> <20080618201125.GG24043@scytale.galois.com> <20080619160646.GA21711@craft> <200806192124.37772.dan.doel@gmail.com> <953e0d250806200101l643878ceq480a22c5906ce8c@mail.gmail.com> <20080620090626.GA2361@soi.city.ac.uk> <20080620184917.GB31722@scytale.galois.com> <20080622055923.GB30974@craft> <485FFBA6.4020900@list.mightyreason.com> <1214257218.15010.1041.camel@localhost> Message-ID: <873an2iuj3.wl%jeremy@n-heptane.com> At Mon, 23 Jun 2008 22:40:18 +0100, Duncan Coutts wrote: > Yes. I agree. It's not even necessarily the author themselves that would > necessarily mark a package as obsolete or without maintainers or > whatever. On a slightly related note, I would be more likely to fix my broken packages on hackageDB, if hackageDB automatically sent me an email when a package breaks. j. From ndmitchell at gmail.com Tue Jun 24 14:01:26 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Jun 24 13:52:57 2008 Subject: Package spam :-) In-Reply-To: <873an2iuj3.wl%jeremy@n-heptane.com> References: <4858F398.20708@iee.org> <20080619160646.GA21711@craft> <200806192124.37772.dan.doel@gmail.com> <953e0d250806200101l643878ceq480a22c5906ce8c@mail.gmail.com> <20080620090626.GA2361@soi.city.ac.uk> <20080620184917.GB31722@scytale.galois.com> <20080622055923.GB30974@craft> <485FFBA6.4020900@list.mightyreason.com> <1214257218.15010.1041.camel@localhost> <873an2iuj3.wl%jeremy@n-heptane.com> Message-ID: <404396ef0806241101x3acf3938uf0ed4a1537441e0c@mail.gmail.com> Hi > > Yes. I agree. It's not even necessarily the author themselves that would > > necessarily mark a package as obsolete or without maintainers or > > whatever. > > On a slightly related note, I would be more likely to fix my broken > packages on hackageDB, if hackageDB automatically sent me an > email when a package breaks. Me too! Or when new warnings get added to the hackage system which would cause a warning on a new upload, or when haddock or GHC fails to build the package. York University has a particularly effective way of ensuring everyone uses valid HTML, by sending an email once a week if there is any invalid HTML. Perhaps this would be going too far, but alerting maintainers to the problems would be handy. Thanks Neil From ndmitchell at gmail.com Tue Jun 24 14:09:20 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Jun 24 14:00:52 2008 Subject: [Ticket #2393] Text.PrettyPrint.HughesPJ: Bug fixes, performance improvement In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE70CC842@EA-EXMSG-C334.europe.corp.microsoft.com> References: <755307ED-284E-4DBF-AF8E-2BEEAD64248D@gmail.com> <1F6084B0-7E94-461D-AA21-B6FEFC089852@gmx.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE70CC842@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <404396ef0806241109k28d3d316v78d091bded549d9d@mail.gmail.com> Hi Benedikt, Great work, and many thanks! One ticket that might be interesting, while you are in the area, is: http://hackage.haskell.org/trac/ghc/ticket/1217 The code is attached, I went through all the API review months and months ago, and everyone agreed that the function should be added, but under the name "zeroWidthText". I'm guessing it isn't too much effort to tack this on while you are working on it? I am currently limited to Hugs only (not enough disk space to install GHC and no SSH access...), so am unable to patch any libraries myself. Thanks Neil On 6/24/08, Simon Peyton-Jones wrote: > Thank you for doing this Benedict. I've added your more detailed comments to ticket #2393 so that they are preserved. > > Ian: would you like to apply? I'm not sure how to integrate the QuickCheck tests, but I bet you know. > > > Benedict: while you are in the area, would you like to take a swing at http://hackage.haskell.org/trac/ghc/ticket/1337, and 1176? > > Simon > > > > | -----Original Message----- > | From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Benedikt Huber > | Sent: 24 June 2008 13:12 > | To: libraries@haskell.org > | Subject: [Ticket #2393] Text.PrettyPrint.HughesPJ: Bug fixes, performance improvement > | > | Hello, > | > | I'd like to propose bugfixes, documentation fixes and a performance > | improvement for Text.PrettyPrint.HughesPJ. The changes shouldn't > | effect the expected behaviour of the PP library. > | > | I've written a QuickCheck test suite for the pretty printer (to test > | the improvement), and found two bugs and some misconceptions/ > | ambiguities in the documentation. Additionally, there is a > | microbenchmark for the suggested improvement. > | Both are available at http://code.haskell.org/~bhuber/Text/ > | PrettyPrint/. Note that the QuickCheck tests need access to all top- > | level names in HughesPJ (i.e. ignore the export list). > | > | In summary, I propose to > | * fix a bug in fillNB and one in fillNB/sepNB > | * correct documentation on laws and invariants. > | * add more efficient implementations of vcat,hsep,hcat > | > | More specifically: > | > | (1) Bugfix fillNB: Additional case for fillNB Empty (Empty : ys) > | > | (2) Bugfix [f](cat|sep): do not allow overlapping ($$) in vertical > | composition > | > | (3) Lazy implementations of vcat,hcat and hsep > | > | (4) Law isn't always true > | > | (5) Invariant 5 should be made stronger > | > | (6) Change the comment about negative indentation > | > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From bulat.ziganshin at gmail.com Tue Jun 24 14:05:16 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Jun 24 14:23:04 2008 Subject: [Ticket #2393] Text.PrettyPrint.HughesPJ: Bug fixes, performance improvement In-Reply-To: <404396ef0806241109k28d3d316v78d091bded549d9d@mail.gmail.com> References: <755307ED-284E-4DBF-AF8E-2BEEAD64248D@gmail.com> <1F6084B0-7E94-461D-AA21-B6FEFC089852@gmx.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE70CC842@EA-EXMSG-C334.europe.corp.microsoft.com> <404396ef0806241109k28d3d316v78d091bded549d9d@mail.gmail.com> Message-ID: <315922590.20080624220516@gmail.com> Hello Neil, Tuesday, June 24, 2008, 10:09:20 PM, you wrote: > working on it? I am currently limited to Hugs only (not enough disk > space to install GHC and no SSH access...) is it prison or university? ;) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From duncan.coutts at worc.ox.ac.uk Tue Jun 24 14:37:02 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jun 24 14:23:27 2008 Subject: Package spam :-) In-Reply-To: <404396ef0806241101x3acf3938uf0ed4a1537441e0c@mail.gmail.com> References: <4858F398.20708@iee.org> <20080619160646.GA21711@craft> <200806192124.37772.dan.doel@gmail.com> <953e0d250806200101l643878ceq480a22c5906ce8c@mail.gmail.com> <20080620090626.GA2361@soi.city.ac.uk> <20080620184917.GB31722@scytale.galois.com> <20080622055923.GB30974@craft> <485FFBA6.4020900@list.mightyreason.com> <1214257218.15010.1041.camel@localhost> <873an2iuj3.wl%jeremy@n-heptane.com> <404396ef0806241101x3acf3938uf0ed4a1537441e0c@mail.gmail.com> Message-ID: <1214332622.15010.1103.camel@localhost> On Tue, 2008-06-24 at 19:01 +0100, Neil Mitchell wrote: > Hi > > > > Yes. I agree. It's not even necessarily the author themselves that would > > > necessarily mark a package as obsolete or without maintainers or > > > whatever. > > > > On a slightly related note, I would be more likely to fix my broken > > packages on hackageDB, if hackageDB automatically sent me an > > email when a package breaks. > > Me too! Or when new warnings get added to the hackage system which > would cause a warning on a new upload, or when haddock or GHC fails to > build the package. > > York University has a particularly effective way of ensuring everyone > uses valid HTML, by sending an email once a week if there is any > invalid HTML. Perhaps this would be going too far, but alerting > maintainers to the problems would be handy. Yes. Once our data on build outcomes is of sufficient quality to not just annoy everyone then I think we should have hackage email maintainers. At the moment we only check packages once at upload time and never again. Also even when they do fail, as often as not it's not really the package author's fault (eg diamond dep errors, missing C libs). Duncan From ashley at semantic.org Tue Jun 24 15:10:18 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Tue Jun 24 15:01:51 2008 Subject: PROPOSAL: Make Applicative a superclass of Monad In-Reply-To: <20080624111441.46f4112a.Malcolm.Wallace@cs.york.ac.uk> References: <20080624111441.46f4112a.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <4861469A.5020407@semantic.org> Malcolm Wallace wrote: > I'm strongly against. > > Some datatypes have several different possible implementations of > Applicative, for instance, they may be either lazy or strict. The > PolyParse library relies crucially on the fact that the Monad and > Applicative instances for the Parser type have different strictness > behaviours. > > I worry that if Applicative were to become a superclass of Monad, this > way of partitioning my API into lazy and strict portions may no longer > be possible, or least, a good deal less convenient. Do you have an example of this? I should make (>>) a member of Applicative. Would that address you concern? Or are (Applicative) pure and (Monad) return different for your type? I intend to re-submit this for Haskell Prime. -- Ashley Yakeley From ross at soi.city.ac.uk Tue Jun 24 16:22:07 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Jun 24 16:13:41 2008 Subject: PROPOSAL: Make Applicative a superclass of Monad In-Reply-To: <20080624111441.46f4112a.Malcolm.Wallace@cs.york.ac.uk> References: <20080624111441.46f4112a.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <20080624202207.GA17938@soi.city.ac.uk> On Tue, Jun 24, 2008 at 11:14:41AM +0100, Malcolm Wallace wrote: > Some datatypes have several different possible implementations of > Applicative, for instance, they may be either lazy or strict. The > PolyParse library relies crucially on the fact that the Monad and > Applicative instances for the Parser type have different strictness > behaviours. I think you're abusing the class, and it's bound to go wrong sooner or later. A monad is morally an applicative functor, and clients ought to be able to assume, as the docs say, that pure = return and (<*>) = ap. The lazy and strict things should be different types. From ashley at semantic.org Tue Jun 24 18:16:13 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Tue Jun 24 18:07:52 2008 Subject: PROPOSAL: Make Applicative a superclass of Monad In-Reply-To: <20080624115515.GC17344@matrix.chaos.earth.li> References: <20080624115515.GC17344@matrix.chaos.earth.li> Message-ID: <4861722D.2050309@semantic.org> Ian Lynagh wrote: > On Tue, Jun 24, 2008 at 02:15:19AM -0700, Ashley Yakeley wrote: >> http://hackage.haskell.org/trac/ghc/ticket/2392 >> >> Make Applicative (in Control.Applicative) a superclass of Monad (in >> Control.Monad). > > I agree with what other people have said about H98 compatibility. I > think you would be better off proposing this for Haskell'. OK. Please close it, and I'll submit it for Prime. Thanks -- Ashley Yakeley From ajb at spamcop.net Tue Jun 24 19:51:40 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Tue Jun 24 19:43:11 2008 Subject: PROPOSAL: Make Applicative a superclass of Monad In-Reply-To: <4860FD53.3080002@charter.net> References: <814962006.20080624133014@gmail.com> <4860FD53.3080002@charter.net> Message-ID: <20080624195140.7xz1km59w848o0gk-nwo@webmail.spamcop.net> G'day all. Quoting Isaac Dupree : > Is there any practical way we can make this change while still making > it possible to compile Haskell98 programs at all? This is being redirected to haskell-prime, of course, however, while we're on the topic, it needs to be said yet again: It's a severe pain to make class hierarchies more granular if you have to declare an instance for all of them. I support the principle of making Applicative a superclass of Monad. However, I don't want to have to declare an instance for Functor and Applicative just to declare an instance for Monad. There are obvious defaults, and I should be able to get them with no effort, or at the very least, no more effort than a "deriving"-like annotation. Cheers, Andrew Bromage From duncan.coutts at worc.ox.ac.uk Tue Jun 24 20:07:06 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jun 24 19:53:29 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: <288267141.20080624182903@gmail.com> References: <20080623090559.GA2836@soi.city.ac.uk> <1214257903.15010.1053.camel@localhost> <404396ef0806231506r50320a8h4c95af327da657f@mail.gmail.com> <20080624002844.GB8531@soi.city.ac.uk> <404396ef0806231744m58d5c04fo3d82aa5627cef716@mail.gmail.com> <4860F9D8.5060800@charter.net> <288267141.20080624182903@gmail.com> Message-ID: <1214352426.15010.1122.camel@localhost> On Tue, 2008-06-24 at 18:29 +0400, Bulat Ziganshin wrote: > i think that Hackage should be database of ALL packages, and other > ways should be used to distinguish between better and worse ones > (such as download count, maintainer field, version, last update time...) Yes. The archive is supposed to be persistent. We don't want to be deleting packages just because they have suffered bit rot. Of course we also need to be able to present to users the subset of current working maintained packages that we actually suggest that they use (using all the metadata you mention). Duncan From john at repetae.net Tue Jun 24 20:39:47 2008 From: john at repetae.net (John Meacham) Date: Tue Jun 24 20:31:17 2008 Subject: PROPOSAL: Make Applicative a superclass of Monad In-Reply-To: <4860FD53.3080002@charter.net> References: <814962006.20080624133014@gmail.com> <4860FD53.3080002@charter.net> Message-ID: <20080625003947.GH12977@sliver.repetae.net> On Tue, Jun 24, 2008 at 09:57:39AM -0400, Isaac Dupree wrote: > Is there any practical way we can make this change while still making it > possible to compile Haskell98 programs at all? It seems that even with a > compiler flag, it will be difficult to do with current haskell > implementations (at the very least, a different Monad class would have to > be exported from haskell98 modules than from... modern modules.) This is one of the issue 'class aliases' were created to address. John -- John Meacham - ?repetae.net?john? From apfelmus at quantentunnel.de Wed Jun 25 04:09:33 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Wed Jun 25 04:01:14 2008 Subject: Generic tries (long) In-Reply-To: <485F74CC.8080504@iee.org> References: <10ed1a750806161228t12b974dx18395853e2b9e5f2@mail.gmail.com> <10ed1a750806181516o1e46cd7fp7d288631f20f9bd4@mail.gmail.com> <485B8BBC.9030303@iee.org> <485F74CC.8080504@iee.org> Message-ID: Adrian Hey wrote: > The type of the proposed merge now seems similarly strange to me.. > > merge :: (k -> Maybe a -> Maybe b -> Maybe c) -> map a -> map b -> map c > > This requres users to define a function argument that is presumably of > form > > f k Nothing Nothing = undefined > f k (Just a) Nothing = fa k a > f k (Just a) (Just b) = fab k a b > f k Nothing (Just b) = fb k b > > Why not just pass fa,fab and fb directly, which will be more convenient > for both users and implementors I think.. > > merge :: (k -> a -> Maybe c) -> > (k -> a -> b -> Maybe c) -> > (k -> b -> Maybe c) -> > map a -> map b -> map c While every such f must have this form, in the sense that \f k -> (\a -> f k (Just a) Nothing , \a b -> f k (Just a) (Just b), \b -> f k Nothing (Just b)) is an isomorphism, it doesn't mean that it's explicitly implemented that way. The intention was that the library exports ready-made functions union, intersect, difference :: k -> Maybe a -> Maybe a -> Maybe a and combinators like unionWith :: (k -> a -> b -> c) -> (k -> Maybe a -> Maybe b -> Maybe c) that can be plugged into merge , like merge intersect merge (unionWith $ curry snd) Thus, the user doesn't implement the argument to merge himself unless he requires custom behavior. Hence, using one argument instead of three is more convenient here. The particular form union, intersect, difference :: Maybe a -> Maybe a -> Maybe a has mnemonic value as well, since Maybe a is the finite map with one element, so the combinator intersect actually intersects two finite maps. You're probably right concerning the efficiency of merge . The problem is that merge may decide per element whether to intersect, union, difference or something, while the original intersect may only intersect elements and can hence throw whole subtrees away without looking into them. An signature for merge that does not allow per-element tests would be merge :: (Bool -> Bool -> Bool) -> (k -> a -> b -> c) -> map a -> map b -> map c Here, the boolean function determines membership while the second argument determines how to merge two values. There is the small problem that the boolean function f ought to fulfill f False False = False. This can be guaranteed by using a rank-2 type merge :: (forall a. Maybe a -> Maybe a -> Maybe a) -> ... Incidentally, this restores the fact that the first argument combines one-element finite maps. Regards, apfelmus From benjovi at gmx.net Wed Jun 25 08:41:20 2008 From: benjovi at gmx.net (Benedikt Huber) Date: Wed Jun 25 08:32:54 2008 Subject: [Ticket #2393] Text.PrettyPrint.HughesPJ: Bug fixes, performance improvement In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE70CC842@EA-EXMSG-C334.europe.corp.microsoft.com> References: <755307ED-284E-4DBF-AF8E-2BEEAD64248D@gmail.com> <1F6084B0-7E94-461D-AA21-B6FEFC089852@gmx.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE70CC842@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <48623CF0.10604@gmx.net> Simon Peyton-Jones schrieb: > Thank you for doing this Benedict. I've added your more detailed comments to ticket #2393 so that they are preserved. > > Ian: would you like to apply? I'm not sure how to integrate the QuickCheck tests, but I bet you know. I'm glad this is useful - and I'm impressed by the complexity of the pretty printer library. I'm tackling the other tickets now and adding more QuickCheck test. > Benedict: while you are in the area, would you like to take a swing at http://hackage.haskell.org/trac/ghc/ticket/1337, and 1176? In my opinion, ticket #667 can be marked invalid (see comments). Concerning ticket #1337, we have to change the formal specification of fill (it doesn't match the implementation): -- Current Specification: -- fill [] = empty -- fill [p] = p -- fill (p1:p2:ps) = oneLiner p1 <#> nest (length p1) -- (fill (oneLiner p2 : ps)) -- `union` -- p1 $$ fill ps Problem 1: We want to `unnest' the second argument of (p1 $$ fill ps), but not the first one In the definition above we have e.g. > getSecondLayout $ > fillDef False [text "a", text "b", text "a"] >> text "ab"; nilabove; nest -1; text "a"; empty >> |ab| >> |.a| Problem 2: The overlapping $$ should only be used for those layouts of p1 which aren't one liners (otherwise violating the invariant "Left union arg has shorter first line"). I suggest the following specification (i believe it almost matches the current implementation, modulo [fillNB: fix bug #1337] (see below): -- Revised Specification: -- fill g docs = fill' 0 docs -- gap g = if g then 1 else 0 -- fill' n [] = [] -- fill' n [p] = [p] -- fill' n (p1:p2:ps) = -- oneLiner p1 (fill' (n+length p1+gap g) (oneLiner p2 : ps)) -- `union` -- (p1 $*$ nest (-n) (fill' g ps)) -- -- $*$ is defined for layouts (One-Layout Documents) as -- -- layout1 $*$ layout2 | isOneLiner layout1 = layout1 $+$ layout2 -- | otherwise = layout1 $$ layout2 I've also implemented the specification in HughesPJQuickCheck.hs, and checked them against the patched pretty printer. Concerning Bug #1337: ~~~~~~~~~~~~~~~~~~~~~ If the above formal specification is fine, it is easy to fix: elide the nests of (oneLiner p2) [see attached patch, record bug #1337]. > PrettyPrint(0) $ ./Bug1337 > ....ab > ...c The (long) explanation follows below. I'll look into the other tickets too. thorkil: Can you help me with a simplified test case (pretty printer only) of Bug #1176 ? Also, I didn't find any regressions tests for the pretty printer - I'll create some if someone points me in the right direction. best regards, benedikt =========================================================== Explanation of Bug #1337: Consider > fcat [ nest 1 $ text "a", nest 2 $ text "b", text "c"] --> expected: (nest 1; text "a"; text "b"; nest -3; "c") --> actual : (nest 1; text "a"; text "b"; nest -5; "c") Reduction: === (nest 1; text a) <> (fill (-2) (p2:ps)) ==> (nest 2 (text "b") $+$ text "c") ==> (nest 2 (text "b")) `nilabove` (nest (-3) (text "c")) ==> (nest 1; text a; text b; nest -5 c) The problem is that if we decide to layout (p1:p2:ps) as | p1 p2 | ps (call it layout A), then we want to have > (p1 <> p2) $+$ ps. But following law this means that > fcat_A [p1:nest k p2:ps] is equivalent to > fcat_A [p1,p2,ps] so the nest of p2 has to be removed. This is somewhat similar to bug #667, but easier to fix from a semantic point of view: p1,p2 and ps are distinct layouts - we only have to preserve the individual layouts, and no combinations of them. > > Simon > > > | -----Original Message----- > | From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Benedikt Huber > | Sent: 24 June 2008 13:12 > | To: libraries@haskell.org > | Subject: [Ticket #2393] Text.PrettyPrint.HughesPJ: Bug fixes, performance improvement > | > | Hello, > | > | I'd like to propose bugfixes, documentation fixes and a performance > | improvement for Text.PrettyPrint.HughesPJ. The changes shouldn't > | effect the expected behaviour of the PP library. > | > | I've written a QuickCheck test suite for the pretty printer (to test > | the improvement), and found two bugs and some misconceptions/ > | ambiguities in the documentation. Additionally, there is a > | microbenchmark for the suggested improvement. > | Both are available at http://code.haskell.org/~bhuber/Text/ > | PrettyPrint/. Note that the QuickCheck tests need access to all top- > | level names in HughesPJ (i.e. ignore the export list). > | > | In summary, I propose to > | * fix a bug in fillNB and one in fillNB/sepNB > | * correct documentation on laws and invariants. > | * add more efficient implementations of vcat,hsep,hcat > | > | More specifically: > | > | (1) Bugfix fillNB: Additional case for fillNB Empty (Empty : ys) > | > | (2) Bugfix [f](cat|sep): do not allow overlapping ($$) in vertical > | composition > | > | (3) Lazy implementations of vcat,hcat and hsep > | > | (4) Law isn't always true > | > | (5) Invariant 5 should be made stronger > | > | (6) Change the comment about negative indentation > | -------------- next part -------------- New patches: [fillNB bug, lazy vcat benedikt.huber@gmail.com**20080624113715] { hunk ./Text/PrettyPrint/HughesPJ.hs 410 + +** because of law n6, t2 only holds if x doesn't +** start with `nest'. + hunk ./Text/PrettyPrint/HughesPJ.hs 429 - (text s <> x) $$ y = text s <> ((text "" <> x)) $$ - nest (-length s) y) + (text s <> x) $$ y = text s <> ((text "" <> x) $$ + nest (-length s) y) hunk ./Text/PrettyPrint/HughesPJ.hs 490 +-- lazy list versions +hcat = reduceAB . foldr (beside_' False) empty +hsep = reduceAB . foldr (beside_' True) empty +vcat = reduceAB . foldr (above_' True) empty hunk ./Text/PrettyPrint/HughesPJ.hs 495 -hcat = foldr (<>) empty -hsep = foldr (<+>) empty -vcat = foldr ($$) empty +beside_' :: Bool -> Doc -> Doc -> Doc +beside_' _ p Empty = p +beside_' g p q = Beside p g q + +above_' :: Bool -> Doc -> Doc -> Doc +above_' _ p Empty = p +above_' g p q = Above p g q + +reduceAB :: Doc -> Doc +reduceAB (Above Empty _ q) = q +reduceAB (Beside Empty _ q) = q +reduceAB doc = doc hunk ./Text/PrettyPrint/HughesPJ.hs 556 - * The arugment of @TextBeside@ is never @Nest@. + * The argument of @TextBeside@ is never @Nest@. hunk ./Text/PrettyPrint/HughesPJ.hs 564 - * The right argument of a union cannot be equivalent to the empty set - (@NoDoc@). If the left argument of a union is equivalent to the - empty set (@NoDoc@), then the @NoDoc@ appears in the first line. + * A @NoDoc@ may only appear on the first line of the left argument of an + union. Therefore, the right argument of an union can never be equivalent + to the empty set (@NoDoc@). hunk ./Text/PrettyPrint/HughesPJ.hs 578 - -- Arg of a NilAbove is always an RDoc -nilAbove_ :: Doc -> Doc +-- Invariant: Args to the 4 functions below are always RDocs +nilAbove_ :: RDoc -> RDoc hunk ./Text/PrettyPrint/HughesPJ.hs 583 -textBeside_ :: TextDetails -> Int -> Doc -> Doc +textBeside_ :: TextDetails -> Int -> RDoc -> RDoc hunk ./Text/PrettyPrint/HughesPJ.hs 586 - -- Arg of Nest is always an RDoc -nest_ :: Int -> Doc -> Doc +nest_ :: Int -> RDoc -> RDoc hunk ./Text/PrettyPrint/HughesPJ.hs 589 - -- Args of union are always RDocs -union_ :: Doc -> Doc -> Doc +union_ :: RDoc -> RDoc -> RDoc hunk ./Text/PrettyPrint/HughesPJ.hs 765 - nilAboveNest False k (reduceDoc (vcat ys)) + nilAboveNest True k (reduceDoc (vcat ys)) hunk ./Text/PrettyPrint/HughesPJ.hs 810 -fillNB g Empty k (y:ys) = nilBeside g (fill1 g (oneLiner (reduceDoc y)) k1 ys) +fillNB g Empty k (Empty:ys) = fillNB g Empty k ys +fillNB g Empty k (y:ys) = fillNBE g k y ys +fillNB g p k ys = fill1 g p k ys + +fillNBE g k y ys = nilBeside g (fill1 g (oneLiner (reduceDoc y)) k1 ys) hunk ./Text/PrettyPrint/HughesPJ.hs 816 - nilAboveNest False k (fill g (y:ys)) + nilAboveNest True k (fill g (y:ys)) hunk ./Text/PrettyPrint/HughesPJ.hs 821 -fillNB g p k ys = fill1 g p k ys - - hunk ./Text/PrettyPrint/HughesPJ.hs 1039 --- It should never be called with 'n' < 0, but that can happen for reasons I don't understand --- Here's a test case: --- ncat x y = nest 4 $ cat [ x, y ] --- d1 = foldl1 ncat $ take 50 $ repeat $ char 'a' --- d2 = parens $ sep [ d1, text "+" , d1 ] --- main = print d2 --- I don't feel motivated enough to find the Real Bug, so meanwhile we just test for n<=0 +-- returns the empty string on negative argument. +-- hunk ./Text/PrettyPrint/HughesPJ.hs 1045 -{- Comments from Johannes Waldmann about what the problem might be: +{- +Concerning negative indentation: +If we compose a <> b, and the first line of b is deeply nested, but other lines of b are not, +then, because <> eats the nest, the pretty printer will try to layout some of b's lines with +negative indentation: hunk ./Text/PrettyPrint/HughesPJ.hs 1051 - In the example above, d2 and d1 are deeply nested, but `text "+"' is not, - so the layout function tries to "out-dent" it. - - when I look at the Doc values that are generated, there are lots of - Nest constructors with negative arguments. see this sample output of - d1 (obtained with hugs, :s -u) - - tBeside (TextDetails_Chr 'a') 1 Doc_Empty) (Doc_NilAbove (Doc_Nest - (-241) (Doc_TextBeside (TextDetails_Chr 'a') 1 Doc_Empty))))) - (Doc_NilAbove (Doc_Nest (-236) (Doc_TextBeside (TextDetails_Chr 'a') 1 - (Doc_NilAbove (Doc_Nest (-5) (Doc_TextBeside (TextDetails_Chr 'a') 1 - Doc_Empty)))))))) (Doc_NilAbove (Doc_Nest (-231) (Doc_TextBeside - (TextDetails_Chr 'a') 1 (Doc_NilAbove (Doc_Nest (-5) (Doc_TextBeside - (TextDetails_Chr 'a') 1 (Doc_NilAbove (Doc_Nest (-5) (Doc_TextBeside - (TextDetails_Chr 'a') 1 Doc_Empty))))))))))) (Doc_NilAbove (Doc_Nest +doc |0123345 +------------------ +d1 |a +d2 | b + |c +d1<>d2 |ab + c| } [fillNB: fix bug #1337 benedikt.huber@gmail.com**20080625114659] { hunk ./Text/PrettyPrint/HughesPJ.hs 814 -fillNBE g k y ys = nilBeside g (fill1 g (oneLiner (reduceDoc y)) k1 ys) +fillNBE g k y ys = nilBeside g (fill1 g (elideNest . oneLiner . reduceDoc $ y) k1 ys) hunk ./Text/PrettyPrint/HughesPJ.hs 820 - +elideNest (Nest k d) = d +elideNest d = d } Context: [Fix warnings Ian Lynagh **20080620135156] [TAG 2008-05-28 Ian Lynagh **20080528004408] Patch bundle hash: 1c1d36f58462f5c86700d37fb4d7729461aea35c From benjovi at gmx.net Wed Jun 25 10:03:45 2008 From: benjovi at gmx.net (Benedikt Huber) Date: Wed Jun 25 09:55:18 2008 Subject: [Ticket #2393] Text.PrettyPrint.HughesPJ: Bug fixes, performance improvement In-Reply-To: <404396ef0806241109k28d3d316v78d091bded549d9d@mail.gmail.com> References: <755307ED-284E-4DBF-AF8E-2BEEAD64248D@gmail.com> <1F6084B0-7E94-461D-AA21-B6FEFC089852@gmx.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE70CC842@EA-EXMSG-C334.europe.corp.microsoft.com> <404396ef0806241109k28d3d316v78d091bded549d9d@mail.gmail.com> Message-ID: <48625041.1090108@gmx.net> Neil Mitchell schrieb: > Hi Benedikt, > > Great work, and many thanks! > > One ticket that might be interesting, while you are in the area, is: > > http://hackage.haskell.org/trac/ghc/ticket/1217 > > The code is attached, I went through all the API review months and > months ago, and everyone agreed that the function should be added, but > under the name "zeroWidthText". Hi Neil, Thanks ! Concerning #1217: http://www.haskell.org/pipermail/libraries/2007-March/007028.html I'm not quite sure what you are asking for - I'm not the one to apply the patches ;) From a technical point of view, zeroWidthText wouldn't cause any bugs in the current implementation, as far as I can see. Two things should be considered though: 1) when defining zeroTextWidth as (textBeside_ (Str s) 0 Empty), the client looses the information that (Str s) is a zero-width TextDetail. When combining the text again (see string_txt for example), it might be good to know that. I do not suggest it, but it /might/ be worth to consider using a different constructor for zero width texts. Of course, this modifies the API, as TextDetails is exported. Btw, is there any use for the (PStr :: String -> TextDetails) constructor ? 2) One has to take precautions that future versions of the library do not use the text length for optimizations. For example the law > text "" <> s = elide_nests s must not be used by testing against the text length (which is the obvious and fasted way to do so). Some regression tests would be a good idea. -- Btw: the people commenting in the thread linked above seemed to be using different pretty printer libraries, so maybe some comments from actual users would be good too. cheers, benedikt > > I'm guessing it isn't too much effort to tack this on while you are > working on it? I am currently limited to Hugs only (not enough disk > space to install GHC and no SSH access...), so am unable to patch any > libraries myself. > > Thanks > > Neil > > > On 6/24/08, Simon Peyton-Jones wrote: >> Thank you for doing this Benedict. I've added your more detailed comments to ticket #2393 so that they are preserved. >> >> Ian: would you like to apply? I'm not sure how to integrate the QuickCheck tests, but I bet you know. >> >> >> Benedict: while you are in the area, would you like to take a swing at http://hackage.haskell.org/trac/ghc/ticket/1337, and 1176? >> >> Simon >> >> >> >> | -----Original Message----- >> | From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Benedikt Huber >> | Sent: 24 June 2008 13:12 >> | To: libraries@haskell.org >> | Subject: [Ticket #2393] Text.PrettyPrint.HughesPJ: Bug fixes, performance improvement >> | >> | Hello, >> | >> | I'd like to propose bugfixes, documentation fixes and a performance >> | improvement for Text.PrettyPrint.HughesPJ. The changes shouldn't >> | effect the expected behaviour of the PP library. >> | >> | I've written a QuickCheck test suite for the pretty printer (to test >> | the improvement), and found two bugs and some misconceptions/ >> | ambiguities in the documentation. Additionally, there is a >> | microbenchmark for the suggested improvement. >> | Both are available at http://code.haskell.org/~bhuber/Text/ >> | PrettyPrint/. Note that the QuickCheck tests need access to all top- >> | level names in HughesPJ (i.e. ignore the export list). >> | >> | In summary, I propose to >> | * fix a bug in fillNB and one in fillNB/sepNB >> | * correct documentation on laws and invariants. >> | * add more efficient implementations of vcat,hsep,hcat >> | >> | More specifically: >> | >> | (1) Bugfix fillNB: Additional case for fillNB Empty (Empty : ys) >> | >> | (2) Bugfix [f](cat|sep): do not allow overlapping ($$) in vertical >> | composition >> | >> | (3) Lazy implementations of vcat,hcat and hsep >> | >> | (4) Law isn't always true >> | >> | (5) Invariant 5 should be made stronger >> | >> | (6) Change the comment about negative indentation >> | >> >> _______________________________________________ >> Libraries mailing list >> Libraries@haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> From ndmitchell at gmail.com Wed Jun 25 11:58:49 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Jun 25 11:50:17 2008 Subject: [Ticket #2393] Text.PrettyPrint.HughesPJ: Bug fixes, performance improvement In-Reply-To: <48625041.1090108@gmx.net> References: <755307ED-284E-4DBF-AF8E-2BEEAD64248D@gmail.com> <1F6084B0-7E94-461D-AA21-B6FEFC089852@gmx.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE70CC842@EA-EXMSG-C334.europe.corp.microsoft.com> <404396ef0806241109k28d3d316v78d091bded549d9d@mail.gmail.com> <48625041.1090108@gmx.net> Message-ID: <404396ef0806250858l63be26a5v3adc7c14f1b3c208@mail.gmail.com> Hi Benedikt, > I'm not quite sure what you are asking for - I'm not the one to apply the > patches ;) The patch needs redoing with zeroWidthText, rather than zeroWidth. I can't build a patch, but you are probably at the right point to do so, and include it into the other patches you are doing. Also, since you seem to understand the low-level details very well, it was a general request for comment. > Two things should be considered though: > > 1) when defining zeroTextWidth as (textBeside_ (Str s) 0 Empty), the client > looses the information that (Str s) is a zero-width TextDetail. > When combining the text again (see string_txt for example), it might be > good to know that. > I do not suggest it, but it /might/ be worth to consider using a different > constructor for zero width texts. Of course, this modifies the API, as > TextDetails is exported. That seems like a bad idea, as I certainly don't know enough details about the library to write the correct implementation in every case, and to be sure there are no pattern-match errors. > 2) One has to take precautions that future versions of the library do not > use the text length for optimizations. > > For example the law > > text "" <> s = elide_nests s > must not be used by testing against the text length (which is the obvious > and fasted way to do so). Some regression tests would be a good idea. True, but I guess that it is currently safe? > Btw: the people commenting in the thread linked above seemed to be using > different pretty printer libraries, so maybe some comments from actual users > would be good too. I think the discussion proceeded enough to be fairly sure that no one objected to it, and lots of people wanted it as part of a general pretty printing library. I think it also showed that lots of serious pretty-printing users had moved away from HughesPJ - its possible your fixes and maintenance might tempt them back. Thanks Neil > > > > > I'm guessing it isn't too much effort to tack this on while you are > > working on it? I am currently limited to Hugs only (not enough disk > > space to install GHC and no SSH access...), so am unable to patch any > > libraries myself. > > > > Thanks > > > > Neil > > > > > > On 6/24/08, Simon Peyton-Jones wrote: > > > > > Thank you for doing this Benedict. I've added your more detailed > comments to ticket #2393 so that they are preserved. > > > > > > Ian: would you like to apply? I'm not sure how to integrate the > QuickCheck tests, but I bet you know. > > > > > > > > > Benedict: while you are in the area, would you like to take a swing at > http://hackage.haskell.org/trac/ghc/ticket/1337, and 1176? > > > > > > Simon > > > > > > > > > > > > | -----Original Message----- > > > | From: libraries-bounces@haskell.org > [mailto:libraries-bounces@haskell.org] On Behalf Of Benedikt Huber > > > | Sent: 24 June 2008 13:12 > > > | To: libraries@haskell.org > > > | Subject: [Ticket #2393] Text.PrettyPrint.HughesPJ: Bug fixes, > performance improvement > > > | > > > | Hello, > > > | > > > | I'd like to propose bugfixes, documentation fixes and a performance > > > | improvement for Text.PrettyPrint.HughesPJ. The changes shouldn't > > > | effect the expected behaviour of the PP library. > > > | > > > | I've written a QuickCheck test suite for the pretty printer (to test > > > | the improvement), and found two bugs and some misconceptions/ > > > | ambiguities in the documentation. Additionally, there is a > > > | microbenchmark for the suggested improvement. > > > | Both are available at > http://code.haskell.org/~bhuber/Text/ > > > | PrettyPrint/. Note that the QuickCheck tests need access to all top- > > > | level names in HughesPJ (i.e. ignore the export list). > > > | > > > | In summary, I propose to > > > | * fix a bug in fillNB and one in fillNB/sepNB > > > | * correct documentation on laws and invariants. > > > | * add more efficient implementations of vcat,hsep,hcat > > > | > > > | More specifically: > > > | > > > | (1) Bugfix fillNB: Additional case for fillNB Empty (Empty : ys) > > > | > > > | (2) Bugfix [f](cat|sep): do not allow overlapping ($$) in vertical > > > | composition > > > | > > > | (3) Lazy implementations of vcat,hcat and hsep > > > | > > > | (4) Law isn't always true > > > | > > > | (5) Invariant 5 should be made stronger > > > | > > > | (6) Change the comment about negative indentation > > > | > > > > > > _______________________________________________ > > > Libraries mailing list > > > Libraries@haskell.org > > > http://www.haskell.org/mailman/listinfo/libraries > > > > > > > > > > From duncan.coutts at worc.ox.ac.uk Wed Jun 25 13:50:37 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jun 25 13:36:55 2008 Subject: [Ticket #2393] Text.PrettyPrint.HughesPJ: Bug fixes, performance improvement In-Reply-To: <48625041.1090108@gmx.net> References: <755307ED-284E-4DBF-AF8E-2BEEAD64248D@gmail.com> <1F6084B0-7E94-461D-AA21-B6FEFC089852@gmx.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE70CC842@EA-EXMSG-C334.europe.corp.microsoft.com> <404396ef0806241109k28d3d316v78d091bded549d9d@mail.gmail.com> <48625041.1090108@gmx.net> Message-ID: <1214416237.15010.1190.camel@localhost> On Wed, 2008-06-25 at 16:03 +0200, Benedikt Huber wrote: > Btw, is there any use for the (PStr :: String -> TextDetails) constructor ? Previously it was used for PackedString (or some predecessor of it) but at some point it got changed to String. There is really very little advantage to PackedString over String because PackedString is very slow. However we should not get rid of the PStr constructor, we should change it to use the new Unicode string type that is in the works. That will be fast and memory efficient (using a similar underlying representation as ByteStrings). So yeah, I suggest we leave it for now and change it to the new fast unicode text type at some point in the future when that is ready. Duncan From naur at post11.tele.dk Wed Jun 25 15:58:25 2008 From: naur at post11.tele.dk (Thorkil Naur) Date: Wed Jun 25 15:52:14 2008 Subject: [Ticket #2393] Text.PrettyPrint.HughesPJ: Bug fixes, performance improvement In-Reply-To: <48623CF0.10604@gmx.net> References: <755307ED-284E-4DBF-AF8E-2BEEAD64248D@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE70CC842@EA-EXMSG-C334.europe.corp.microsoft.com> <48623CF0.10604@gmx.net> Message-ID: <200806252158.27087.naur@post11.tele.dk> Hello Benedikt, Thanks for all this. From memory, notes, and (last resort) trac search, the HughesPJ-related trac tickets on the GHC trac are: #669 negative indentation in Text.PrettyPrint.HughesPJ #1176 Infinite loop when printing error message #1217 Add zeroText to Text.PrettyPrint.HughesPJ #1337 Fix wrong indentation from Text.PrettyPrint.HughesPJ fill (fcat and fsep) I have added comments to #669 and #1176 that I hope speak for themselves. The problem reported in #1337 has a fix (Fix of wrong indentation from HughesPJ fill (fcat and fsep)), it may still provide some inspiration. On Wednesday 25 June 2008 14:41, Benedikt Huber wrote: > ... > thorkil: Can you help me with a simplified test case (pretty printer > only) of Bug #1176 ? #1176 is a case of #1337 for the internal GHC version of the HughesPJ library and I expect a fix of #1337 to be applicable to the internal GHC library, hence fixing #1176. So I expect the failing cases for #1337 to fail for #1176 as well, but being, unfortunately, somewhat less easily exercised. > Also, I didn't find any regressions tests for the pretty printer - I'll > create some if someone points me in the right direction. The patch (Patch with HughesPJ tests with automated high-level coverage check) attached to #1337 has some tests, but also some rather bombastic things that attempts to ensure some coverage of the tests. This was created at a point in time where hpc was not available. > ... Thanks and best regards Thorkil From aemoncannon at gmail.com Wed Jun 25 18:40:26 2008 From: aemoncannon at gmail.com (Aemon Cannon) Date: Wed Jun 25 18:32:00 2008 Subject: Can't find cabal.exe on windows Message-ID: <794057160806251540h7c1cfebdg5e5ba7175e39588c@mail.gmail.com> I installed Cabal-1.4.01 with ghc 6.8.3 on Windows XP SP2 using the following commands: ghc --make Setup.hs Setup configure Setup build Setup install Everything seemed to work perfectly, but I can't seem to find cabal.exe The README seems to indicate that it'd be installed in HOME/.cabal, but this directory was not created. Any ideas? Thanks, Aemon Cannon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20080625/78e51186/attachment.htm From ndmitchell at gmail.com Wed Jun 25 18:58:04 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Jun 25 18:49:30 2008 Subject: Can't find cabal.exe on windows In-Reply-To: <794057160806251540h7c1cfebdg5e5ba7175e39588c@mail.gmail.com> References: <794057160806251540h7c1cfebdg5e5ba7175e39588c@mail.gmail.com> Message-ID: <404396ef0806251558k2ed88cc5oa37cde888ca11037@mail.gmail.com> Hi Aemon, Try: C:\Documents and Settings\Administrator\Application Data\cabal\bin (changing Administrator for your current user login, possibly) Or: C:\Program Files\Haskell\bin I'd add that to your %PATH%, for convenience. Thanks Neil On 6/25/08, Aemon Cannon wrote: > I installed Cabal-1.4.01 with ghc 6.8.3 on Windows XP SP2 using the > following commands: > > ghc --make Setup.hs > Setup configure > Setup build > Setup install > > > Everything seemed to work perfectly, but I can't seem to find cabal.exe The > README seems to indicate that it'd be installed in HOME/.cabal, but this > directory was not created. > > Any ideas? > > Thanks, > Aemon Cannon > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > From duncan.coutts at worc.ox.ac.uk Wed Jun 25 19:24:19 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jun 25 19:10:33 2008 Subject: Can't find cabal.exe on windows In-Reply-To: <794057160806251540h7c1cfebdg5e5ba7175e39588c@mail.gmail.com> References: <794057160806251540h7c1cfebdg5e5ba7175e39588c@mail.gmail.com> Message-ID: <1214436259.15010.1217.camel@localhost> On Wed, 2008-06-25 at 18:40 -0400, Aemon Cannon wrote: > I installed Cabal-1.4.01 with ghc 6.8.3 on Windows XP SP2 using the > following commands: > > ghc --make Setup.hs > Setup configure > Setup build > Setup install > > > Everything seemed to work perfectly, but I can't seem to find > cabal.exe The README seems to indicate that it'd be installed in > HOME/.cabal, but this directory was not created. > > Any ideas? You need to install the "cabal-install" package. The Cabal package is just the library. The "cabal-install" package provides the cabal.exe command line program. The README is right but it's referring to the library. I've added the following to the README which will hopefully make it clearer in future: Installation instructions for the Cabal library =============================================== If you also want the `cabal` command line program then you need the `cabal-install` package in addition to this library. Also I added the following note to the "Installing as a user" section Note the use of the `--user` flag at the configure step. Duncan From ross at soi.city.ac.uk Thu Jun 26 10:10:37 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Jun 26 10:02:05 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: <1214216091.15010.1016.camel@localhost> References: <20080623090559.GA2836@soi.city.ac.uk> <1214216091.15010.1016.camel@localhost> Message-ID: <20080626141037.GA2797@soi.city.ac.uk> On Mon, Jun 23, 2008 at 11:14:51AM +0100, Duncan Coutts wrote: > Looks good to me, except that I think I agree with Gwern that an empty > maintainer field is better than a distinguished value like "none". Is that still your view? > We can always make the web page note that the package has no maintainer. > > If on the other hand everyone thinks "none" is a good idea then we > should make hackage upload enforce that the maintainer field is not > empty. The library already warns about it; all that would be needed is to adjust the severity level. From aemoncannon at gmail.com Thu Jun 26 11:01:51 2008 From: aemoncannon at gmail.com (Aemon Cannon) Date: Thu Jun 26 10:53:16 2008 Subject: Can't find cabal.exe on windows In-Reply-To: <1214436259.15010.1217.camel@localhost> References: <794057160806251540h7c1cfebdg5e5ba7175e39588c@mail.gmail.com> <1214436259.15010.1217.camel@localhost> Message-ID: <794057160806260801w119d8cces5ea5af1edd207867@mail.gmail.com> Ahh, this worked perfectly. Thanks for the help, and thanks everyone for the awesome package manager :) On Wed, Jun 25, 2008 at 7:24 PM, Duncan Coutts wrote: > > On Wed, 2008-06-25 at 18:40 -0400, Aemon Cannon wrote: > > I installed Cabal-1.4.01 with ghc 6.8.3 on Windows XP SP2 using the > > following commands: > > > > ghc --make Setup.hs > > Setup configure > > Setup build > > Setup install > > > > > > Everything seemed to work perfectly, but I can't seem to find > > cabal.exe The README seems to indicate that it'd be installed in > > HOME/.cabal, but this directory was not created. > > > > Any ideas? > > You need to install the "cabal-install" package. The Cabal package is > just the library. The "cabal-install" package provides the cabal.exe > command line program. > > The README is right but it's referring to the library. I've added the > following to the README which will hopefully make it clearer in future: > > Installation instructions for the Cabal library > =============================================== > > If you also want the `cabal` command line program then you need > the `cabal-install` package in addition to this library. > > Also I added the following note to the "Installing as a user" section > > Note the use of the `--user` flag at the configure step. > > > Duncan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20080626/f3e9cbd4/attachment.htm From iavor.diatchki at gmail.com Thu Jun 26 14:03:27 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Thu Jun 26 13:54:52 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: <20080626141037.GA2797@soi.city.ac.uk> References: <20080623090559.GA2836@soi.city.ac.uk> <1214216091.15010.1016.camel@localhost> <20080626141037.GA2797@soi.city.ac.uk> Message-ID: <5ab17e790806261103i458e0aafo62a325e0add6cdd0@mail.gmail.com> Hi, I'd prefer that we omit the maintainer field for packages whose maintainer is unknown. I think that this leads to a cleaner design than choosing an arbitrary distinguished value. -Iavor On Thu, Jun 26, 2008 at 7:10 AM, Ross Paterson wrote: > On Mon, Jun 23, 2008 at 11:14:51AM +0100, Duncan Coutts wrote: >> Looks good to me, except that I think I agree with Gwern that an empty >> maintainer field is better than a distinguished value like "none". > > Is that still your view? > >> We can always make the web page note that the package has no maintainer. >> >> If on the other hand everyone thinks "none" is a good idea then we >> should make hackage upload enforce that the maintainer field is not >> empty. > > The library already warns about it; all that would be needed is to > adjust the severity level. > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From benjovi at gmx.net Thu Jun 26 14:40:22 2008 From: benjovi at gmx.net (Benedikt Huber) Date: Thu Jun 26 14:31:48 2008 Subject: [Ticket #2393] Text.PrettyPrint.HughesPJ: Bug fixes, performance improvement In-Reply-To: <200806252158.27087.naur@post11.tele.dk> References: <755307ED-284E-4DBF-AF8E-2BEEAD64248D@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE70CC842@EA-EXMSG-C334.europe.corp.microsoft.com> <48623CF0.10604@gmx.net> <200806252158.27087.naur@post11.tele.dk> Message-ID: <4863E296.6090002@gmx.net> Thorkil Naur schrieb: > Hello Benedikt, > > Thanks for all this. From memory, notes, and (last resort) trac search, the > HughesPJ-related trac tickets on the GHC trac are: > > #669 negative indentation in Text.PrettyPrint.HughesPJ > #1176 Infinite loop when printing error message > #1217 Add zeroText to Text.PrettyPrint.HughesPJ > #1337 Fix wrong indentation from Text.PrettyPrint.HughesPJ fill (fcat and > fsep) > Hello, I've added a comment to #2393 commenting those bugs: #669 wontfix, #1217 and #1337 fixed in the patch bundle, #1176 propably fixed. So, there is one open issue: the specification of fill. Note that the old specification is flawed and needs to be fixed anyway. Here's the cleaned up, documented version. It looks implementation oriented, but is far simpler than the actual implementation. -- Revised Specification: -- {- start paragraph fill at column 0 -} -- fill g docs = fill' 0 docs -- -- {- base cases -} -- fill' col [] = [] -- fill' col [p] = [p] -- -- {- either put p2 beside p1, or below p1 -} -- fill' col (p1:p2:ps) = -- {- precondition for p1 beside p2: p1,p2 span only one line -} -- {- As we build (p1 <> p2), remove the nesting of p2 -} -- oneLiner p1 -- -- fill' (col + length p1 + gap g) -- (elideNests (oneLiner p2) : ps) -- `union` -- {- put p2 below p1; p2 should be aligned with the first -- argument of fill, which is col columns to the left of p1 -} -- p1 -- $*$ -- nest (-col) (fill' 0 (p2:ps)) -- -- {- width of space -} -- gap g = if g then 1 else 0 -- -- -- $*$ is defined for layouts (One-Layout Documents) as -- -- layout1 $*$ layout2 | isOneLiner layout1 = layout1 $+$ layout2 -- | otherwise = layout1 $$ layout2 -- -- without the the first case, we would violate the one-line lookahead -- invariant The specification of fill' - left alone elideNests and $*$ - does not add any complexity, it is exactly what a paragraph fill should do. elideNests is an improvement - it makes it possible to have nesting in the arguments (otherwise, fill fails with nested arguments). $*$ is a "feature" in the current implementation: It allows overlapping in certain situations. Consider fill |a| , |...c| |b| |...d| Without $*$ ($+$) we would get |a| |b| |...c| |...d| Using $*$ we get |a| |b..c| |...d| I do not know wheter this might be useful - it is an extra feature rarely used I suppose ?? Note that the specification of fill has to be changed anyway, either with $+$ or with $*$. > I have added comments to #669 and #1176 that I hope speak for themselves. The > problem reported in #1337 has a fix (Fix of wrong indentation from HughesPJ > fill (fcat and fsep)), it may still provide some inspiration. Thank you thorkil, I think your patch was correct; the patches in #2393 achieve the same effect. > > On Wednesday 25 June 2008 14:41, Benedikt Huber wrote: >> ... >> thorkil: Can you help me with a simplified test case (pretty printer >> only) of Bug #1176 ? > > #1176 is a case of #1337 for the internal GHC version of the HughesPJ library > and I expect a fix of #1337 to be applicable to the internal GHC library, > hence fixing #1176. So I expect the failing cases for #1337 to fail for #1176 > as well, but being, unfortunately, somewhat less easily exercised. Could you have a look at Bug1176a.hs attached to #1337 ? Is this what happened ? > >> Also, I didn't find any regressions tests for the pretty printer - I'll >> create some if someone points me in the right direction. > > The patch (Patch with HughesPJ tests with automated high-level coverage check) > attached to #1337 has some tests, but also some rather bombastic things that > attempts to ensure some coverage of the tests. This was created at a point in > time where hpc was not available. Ah yes, hpc, thanks for the pointer. Using the quickcheck test suite I found some unused functions and pattern matches. I've added comments to the most important ones. As you seem to know the pretty printer library well, it would be great if you could comment on the revised specification of fill. best regards, benedikt From dons at galois.com Thu Jun 26 17:19:08 2008 From: dons at galois.com (Don Stewart) Date: Thu Jun 26 17:10:39 2008 Subject: Hackage and darcs.haskell.org downtime Message-ID: <20080626211908.GA26002@scytale.galois.com> Galois Inc is moving premises tonight, which means all our servers will be going offline in a few hours, physically moved several miles, and will reappear on a new high speed connection sometime in the following 24 hours. Expect up to 24 hours downtime for all systems hosted on 'monk', including: hackage.haskell.org darcs.haskell.org This will not affect: code.haskell.org www.haskell.org After the move, expect much higher bandwidth to darcs.haskell.org :) -- Don From ahey at iee.org Fri Jun 27 03:25:28 2008 From: ahey at iee.org (Adrian Hey) Date: Fri Jun 27 03:16:58 2008 Subject: Generic tries (long) In-Reply-To: References: <10ed1a750806161228t12b974dx18395853e2b9e5f2@mail.gmail.com> <10ed1a750806181516o1e46cd7fp7d288631f20f9bd4@mail.gmail.com> <485B8BBC.9030303@iee.org> Message-ID: <486495E8.9070304@iee.org> Hello apfelmus, apfelmus wrote: > in alter f .. ? Hm, maybe some zipper-like extension of lookup can do > the trick > > focus :: k -> map a -> (Maybe a, Maybe a -> map a) > > lookup k = fst . focus k > delete k m = case focus k m of > (Nothing, _) -> m > (_ , g) -> g Nothing > alter f k m = case focus k m of > (Nothing, g) -> case f Nothing of > Nothing -> m > x -> g x > (x , g) -> g x I think I prefer this API now, largely because it doesn't require the definition of a new type (per GMap instance presumbly). Only thing I have against it is that it creates another of those weird dual purpose functions that take (Maybe something) as an argument (don't like them much :-). So possibly instead we could have.. focus :: k -> map a -> (Maybe (a -- associated value (if any) ,map a -- k deleted map (unevaluated thunk) ) ,a -> map a -- Insertion/Substitution ) Again, I don't think this could replace alter and friends as a typical zipper implementation will burn as much heap as you're trying to save (twice as much if you go ahead and delete or substitute). But it would avoid an expensive second search in cases where you want the operation combined with a lookup. Instances that can do this cheaper than full zipper (unboxed Int path say) could define their alter,deleteMaybe etc using it if they wanted. (though AFAICS alter can be defined in terms of insertMaybe/deleteMaybe anyway with no efficiency loss). Regards -- Adrian Hey From josef.svenningsson at gmail.com Fri Jun 27 08:57:29 2008 From: josef.svenningsson at gmail.com (Josef Svenningsson) Date: Fri Jun 27 08:48:51 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: <20080623090559.GA2836@soi.city.ac.uk> References: <20080623090559.GA2836@soi.city.ac.uk> Message-ID: <8dde104f0806270557l660a6070j4528dd8968e2fda8@mail.gmail.com> +1 Looks good to me. Josef On Mon, Jun 23, 2008 at 11:05 AM, Ross Paterson wrote: > As a few people have noted, we need to agree a policy in this area. > As I see it, the drivers are: > > * users need to know whether what they're downloading is supported, > and if so by whom. > * maintainers are entitled to control what goes out in their name. > * allocating version numbers for a particular package name should be > the prerogative of the maintainer. > > When something is agreed, I propose to put it on the hackageDB upload > page and expect people to follow it. Here's my first attempt: > > If the Maintainer field names a person or group, the release as > a whole (including packaging) is the named maintainer's approved > release, which they are supporting (at least for some time after > the release). Ideally a maintainer would make that clear by > uploading the release themselves. > > A Maintainer value of "none" indicates that the package is > not supported. > > If a package is being maintained, any release not approved and > supported by the maintainer should use a different package name. > Then use the Maintainer field as above either to commit to > supporting the fork yourself or to mark it as unsupported. > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From dons at galois.com Sat Jun 28 12:54:06 2008 From: dons at galois.com (Don Stewart) Date: Sat Jun 28 12:45:38 2008 Subject: Galois move complete, Hackage back online Message-ID: <20080628165406.GA9207@liouville.galois.com> Galois has completed the move of its data center, and the services: hackage.haskell.org darcs.haskell.org are now back online. Thanks for your patience, everyone! Enjoy the new bandwidth. -- Don From duncan.coutts at worc.ox.ac.uk Sun Jun 29 17:46:47 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Jun 29 17:38:06 2008 Subject: GetOpt formatting improvements Message-ID: <1214776007.7374.19.camel@localhost> GetOpt users, I'd like to have Cabal use the standard System.Console.GetOpt but I'd also like the output to look ok. Currently Cabal uses a private modified version of GetOpt with improved formatting and I'd like to get those improvements into the standard one and eliminate the code duplication. Here's what cabal configure looks like with the standard System.Console.GetOpt. This is what it looks like on a standard 80 column console. In particular note that the descriptions wrap around onto the following lines and look ugly. http://hpaste.org/8626 Here's a little snippet: --enable-library-for-ghci Enable compile library for use with GHCi --disable-library-for-ghci Disable compile library for use wit h GHCi --enable-split-objs Enable split library into smaller ob jects to reduce binary sizes (GHC 6.6+) --disable-split-objs Disable split library into smaller o bjects to reduce binary sizes (GHC 6.6+) --enable-executable-stripping Enable strip executables upon instal lation to reduce binary sizes --disable-executable-stripping Disable strip executables upon insta llation to reduce binary sizes --configure-option=OPT Extra option for configure --user Enable doing a per-user installation --global Disable doing a per-user installatio n --package-db=PATH Use a specific package database (to satisfy dependencies and register in) Here's the same but using the internal modified copy of GetOpt: http://hpaste.org/8626#a1 and the same snippet: --enable-library-for-ghci Enable compile library for use with GHCi --disable-library-for-ghci Disable compile library for use with GHCi --enable-split-objs Enable split library into smaller objects to reduce binary sizes (GHC 6.6+) --disable-split-objs Disable split library into smaller objects to reduce binary sizes (GHC 6.6+) --enable-executable-stripping Enable strip executables upon installation to reduce binary sizes --disable-executable-stripping Disable strip executables upon installation to reduce binary sizes --configure-option=OPT Extra option for configure --user Enable doing a per-user installation --global Disable doing a per-user installation --package-db=PATH Use a specific package database (to satisfy dependencies and register in) So there's two things to notice. One is that we wrap the description so it fits in 80 columns. The other is that we use one space rather than two of padding between the short options, the long options and the description. This gives more space for the description. Actually we go one step further and leave off the args on the short options since they're shown on the long options anyway. I'm not sure everyone wants that so I'm not really proposing it. This is what it looks like: -f FLAGS --flags=FLAGS Force values for the given... vs -f --flags=FLAGS Force values for the given flags in... Similarly: -v[n] --verbose[=n] Control verbosity (n is 0--3,... vs -v --verbose[=n] Control verbosity (n is 0--3, default... So if people think this is sensible I'll send three patches: 1. word-wrap the description to fit in 80 columns 2. use less padding between columns 3. omit the args on short options when there is also a corresponding long option though as I say, perhaps not everyone will think the 3rd change is the right thing to do. Duncan From ndmitchell at gmail.com Sun Jun 29 18:28:54 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun Jun 29 18:20:10 2008 Subject: GetOpt formatting improvements In-Reply-To: <1214776007.7374.19.camel@localhost> References: <1214776007.7374.19.camel@localhost> Message-ID: <404396ef0806291528v4d92a59cpd78762b0194d37d6@mail.gmail.com> Hi > 1. word-wrap the description to fit in 80 columns (+1). 70 and 80 are defensible, anything else seems a bit of a weird choice for line length... > 2. use less padding between columns (+0.8) - given its in columns the spacing is not that necessary, but still slightly nice. Overall, I'd use less padding but don't think the decision is as clear cut (but I still supported it) > 3. omit the args on short options when there is also a > corresponding long option (+1) I recently modified Hoogle to do this, its much more readable, and stops duplicating useless information. The only people who this may confuse are people with less experience, but they should probably use the long options anyway, so it isn't an issue. So agree with all changes. Thanks Neil From malcolm.wallace at cs.york.ac.uk Sun Jun 29 18:34:47 2008 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Sun Jun 29 18:26:06 2008 Subject: GetOpt formatting improvements In-Reply-To: <1214776007.7374.19.camel@localhost> References: <1214776007.7374.19.camel@localhost> Message-ID: > So if people think this is sensible I'll send three patches: > 1. word-wrap the description to fit in 80 columns > 2. use less padding between columns > 3. omit the args on short options when there is also a > corresponding long option These changes all look good to me. The first one is the most vital, the other two I wouldn't mind either way, if anyone else objects for good reason. Regards, Malcolm From isaacdupree at charter.net Sun Jun 29 19:40:59 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Sun Jun 29 19:32:26 2008 Subject: GetOpt formatting improvements In-Reply-To: <1214776007.7374.19.camel@localhost> References: <1214776007.7374.19.camel@localhost> Message-ID: <48681D8B.9080008@charter.net> Duncan Coutts wrote: > Actually we go one step further and leave off the args on the short > options since they're shown on the long options anyway. I'm not sure > everyone wants that so I'm not really proposing it. This is what it > looks like: > > -f FLAGS --flags=FLAGS Force values for the given... > vs > -f --flags=FLAGS Force values for the given flags in... okay.. > Similarly: > > -v[n] --verbose[=n] Control verbosity (n is 0--3,... > vs > -v --verbose[=n] Control verbosity (n is 0--3, default... This confuses me... perhaps because the argument is optional, I don't as easily understand that it's allowed on the short form. What about short-form spacing? is "-v 2" allowed, or only "-v2"? Is this contradictory to the above example where "-f FLAGS" is expected (though probably "-fFLAGS" works too)? maybe these can be resolved somehow without keeping really verbose documentation: what do other people think? Are these cases obscure but nevertheless standard cases of getopt since Unix/GNU history? (e.g. it seems that compilers behave differently from "normal programs", behave differently from everyone else's slightly different implementations of arguments) -Isaac From allbery at ece.cmu.edu Sun Jun 29 19:54:15 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Jun 29 19:45:40 2008 Subject: GetOpt formatting improvements In-Reply-To: <48681D8B.9080008@charter.net> References: <1214776007.7374.19.camel@localhost> <48681D8B.9080008@charter.net> Message-ID: On 2008 Jun 29, at 19:40, Isaac Dupree wrote: > maybe these can be resolved somehow without keeping really verbose > documentation: what do other people think? Are these cases obscure > but nevertheless standard cases of getopt since Unix/GNU history? > (e.g. it seems that compilers behave differently from "normal > programs", behave differently from everyone else's slightly > different implementations of arguments) On of the points of getopt is that -fFLAGS and -f FLAGS both work without any extra code. Standard getopt doesn't do optional arguments at all; GNU getopt handles -vn, -v n, and -v -- or -v -x (for random options -v, -x, the former taking an optional argument; the latter two cases are recognized as argument omitted). (That compilers behave differently is not, IMO, a good thing --- but - l is problematic at best.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From isaacdupree at charter.net Sun Jun 29 20:16:18 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Sun Jun 29 20:07:30 2008 Subject: GetOpt formatting improvements In-Reply-To: References: <1214776007.7374.19.camel@localhost> <48681D8B.9080008@charter.net> Message-ID: <486825D2.3080208@charter.net> Brandon S. Allbery KF8NH wrote: > > On 2008 Jun 29, at 19:40, Isaac Dupree wrote: > >> maybe these can be resolved somehow without keeping really verbose >> documentation: what do other people think? Are these cases obscure >> but nevertheless standard cases of getopt since Unix/GNU history? >> (e.g. it seems that compilers behave differently from "normal >> programs", behave differently from everyone else's slightly different >> implementations of arguments) > > On of the points of getopt is that -fFLAGS and -f FLAGS both work > without any extra code. Standard getopt doesn't do optional arguments > at all; GNU getopt handles -vn, -v n, and -v -- or -v -x (for random > options -v, -x, the former taking an optional argument; the latter two > cases are recognized as argument omitted). ah-ha, so it is an unpleasant behaviour of ambiguity resolution. Oh, well, I don't know what I want. But then saying "-v[n]" to me seems a little more misleading to say than "-v [n]" although they really mean the same thing (what if "-v[n]" makes me think "-v foobar.txt" would pass foobar.txt as a positional argument rather than a verbosity level?). Proposal #3 is to just say "-v". It took me a while to figure out how passing arguments to short and long options worked at all (one requires the presence of "=", the other requires its absence... again, except for exceptions such as ghc), so I might err on the side of being more verbose, less obscure. -Isaac From johan.tibell at gmail.com Mon Jun 30 02:00:00 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon Jun 30 01:51:14 2008 Subject: GetOpt formatting improvements In-Reply-To: <1214776007.7374.19.camel@localhost> References: <1214776007.7374.19.camel@localhost> Message-ID: <90889fe70806292300j356fec4bx58bed95164d55781@mail.gmail.com> On Sun, Jun 29, 2008 at 11:46 PM, Duncan Coutts wrote: > So if people think this is sensible I'll send three patches: > 1. word-wrap the description to fit in 80 columns > 2. use less padding between columns > 3. omit the args on short options when there is also a > corresponding long option What does GNU getopt do in all these cases? I'd prefer if the programs I use on the command line are consistent in their `--help' display and GNU getopt seems to be the standard here. Trying to follow what other people do also makes shell scripting easier. -- Johan From allbery at ece.cmu.edu Mon Jun 30 03:08:02 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Jun 30 02:59:17 2008 Subject: GetOpt formatting improvements In-Reply-To: <90889fe70806292300j356fec4bx58bed95164d55781@mail.gmail.com> References: <1214776007.7374.19.camel@localhost> <90889fe70806292300j356fec4bx58bed95164d55781@mail.gmail.com> Message-ID: <467162F8-C5DC-4771-898A-74EFCFA8B8EF@ece.cmu.edu> On 2008 Jun 30, at 2:00, Johan Tibell wrote: > On Sun, Jun 29, 2008 at 11:46 PM, Duncan Coutts > wrote: >> So if people think this is sensible I'll send three patches: >> 1. word-wrap the description to fit in 80 columns >> 2. use less padding between columns >> 3. omit the args on short options when there is also a >> corresponding long option > > What does GNU getopt do in all these cases? I'd prefer if the programs > I use on the command line are consistent in their `--help' display and > GNU getopt seems to be the standard here. Trying to follow what other > people do also makes shell scripting easier. Options are indented by two spaces. Short options are separated from long by ", ", and that column is left empty if there is no corresponding short option. Option descriptions begin one space after the longest option that doesn't extend past column 30, and word wrap with wrapped lines indented by two additional spaces. If any options go past column 30, their descriptions start one space after the options without attempting to align with the other descriptions, except that wrapped lines are aligned. Practical example: GNU sort > Ordering options: > > Mandatory arguments to long options are mandatory for short options > too. > -b, --ignore-leading-blanks ignore leading blanks > -d, --dictionary-order consider only blanks and alphanumeric > characters > -f, --ignore-case fold lower case to upper case characters > -g, --general-numeric-sort compare according to general numerical > value > -i, --ignore-nonprinting consider only printable characters > -M, --month-sort compare (unknown) < `JAN' < ... < `DEC' > -n, --numeric-sort compare according to string numerical > value > -r, --reverse reverse the result of comparisons > > Other options: > > -c, --check check whether input is sorted; do not sort > -k, --key=POS1[,POS2] start a key at POS1, end it at POS 2 > (origin 1) > -m, --merge merge already sorted files; do not sort > -o, --output=FILE write result to FILE instead of standard > output > -s, --stable stabilize sort by disabling last-resort > comparison > -S, --buffer-size=SIZE use SIZE for main memory buffer > -t, --field-separator=SEP use SEP instead of non-blank to blank > transition > -T, --temporary-directory=DIR use DIR for temporaries, not > $TMPDIR or /tmp; > multiple options specify multiple > directories > -u, --unique with -c, check for strict ordering; > without -c, output only the first of > an equal run > -z, --zero-terminated end lines with 0 byte, not newline > --help display this help and exit > --version output version information and exit Note --help and --version (no short options; also, they're boilerplate and apparently GNU getopt makes no attempt to match their descriptions' indentations with the other options, instead using a tab) and --temporary-directory (ends at column 31; word wrap matches the following option); also note the option groups are aligned independently. Also note the explanatory text about option arguments before the first option group. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From lemming at henning-thielemann.de Mon Jun 30 04:25:15 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Jun 30 04:16:31 2008 Subject: GetOpt formatting improvements In-Reply-To: <1214776007.7374.19.camel@localhost> References: <1214776007.7374.19.camel@localhost> Message-ID: On Sun, 29 Jun 2008, Duncan Coutts wrote: > So if people think this is sensible I'll send three patches: > 1. word-wrap the description to fit in 80 columns Is it possible to adapt this to the actual width of the terminal? From ross at soi.city.ac.uk Mon Jun 30 04:40:28 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Jun 30 04:31:45 2008 Subject: GetOpt formatting improvements In-Reply-To: <404396ef0806291528v4d92a59cpd78762b0194d37d6@mail.gmail.com> References: <1214776007.7374.19.camel@localhost> <404396ef0806291528v4d92a59cpd78762b0194d37d6@mail.gmail.com> Message-ID: <20080630084028.GA2832@soi.city.ac.uk> On Sun, Jun 29, 2008 at 11:28:54PM +0100, Neil Mitchell wrote: > > 1. word-wrap the description to fit in 80 columns > > (+1). 70 and 80 are defensible, anything else seems a bit of a weird > choice for line length... 79 is also defensible, as some terminals wrap if you use the 80th column. From ross at soi.city.ac.uk Mon Jun 30 04:48:09 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Jun 30 04:39:24 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE70CC4FE@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20080623090559.GA2836@soi.city.ac.uk> <1214257903.15010.1053.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C32AE70CC4FE@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20080630084809.GA2985@soi.city.ac.uk> On Tue, Jun 24, 2008 at 01:16:21AM +0100, Simon Peyton-Jones wrote: > (I do rather agree that an explicit "unsupported" would be better than > blank in the maintainer field.) What's your reason for that preference? (We're talking about the text of the .cabal file, rather than what's displayed on the package page.) From jon.fairbairn at cl.cam.ac.uk Mon Jun 30 05:17:47 2008 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Mon Jun 30 05:09:13 2008 Subject: GetOpt formatting improvements References: <1214776007.7374.19.camel@localhost> <404396ef0806291528v4d92a59cpd78762b0194d37d6@mail.gmail.com> <20080630084028.GA2832@soi.city.ac.uk> Message-ID: Ross Paterson writes: > On Sun, Jun 29, 2008 at 11:28:54PM +0100, Neil Mitchell wrote: >> > 1. word-wrap the description to fit in 80 columns >> >> (+1). 70 and 80 are defensible, anything else seems a bit of a weird >> choice for line length... > > 79 is also defensible, as some terminals wrap if you use the 80th column. and 72 is also defensible for historical reasons (cobol rather than fortran, I think). And I use 64 for readability reasons at a particular font size. Making it read the terminal width is clearly the best option. -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2008-04-26) From bulat.ziganshin at gmail.com Mon Jun 30 08:07:41 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Jun 30 08:04:48 2008 Subject: GetOpt formatting improvements In-Reply-To: <20080630084028.GA2832@soi.city.ac.uk> References: <1214776007.7374.19.camel@localhost> <404396ef0806291528v4d92a59cpd78762b0194d37d6@mail.gmail.com> <20080630084028.GA2832@soi.city.ac.uk> Message-ID: <1946566945.20080630160741@gmail.com> Hello Ross, Monday, June 30, 2008, 12:40:28 PM, you wrote: > 79 is also defensible, as some terminals wrap if you use the 80th column. including windows: > type 80 12345678901234567890123456789012345678901234567890123456789012345678901234567890 12345678901234567890123456789012345678901234567890123456789012345678901234567890 12345678901234567890123456789012345678901234567890123456789012345678901234567890 12345678901234567890123456789012345678901234567890123456789012345678901234567890 -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From benjamin.franksen at bessy.de Mon Jun 30 08:25:22 2008 From: benjamin.franksen at bessy.de (Benjamin Franksen) Date: Mon Jun 30 08:16:43 2008 Subject: Takusen build error Message-ID: I get a strange error building Takusen (more precisely: the module Foreign/C/UTF8.hs) with ghc-6.8.3. It says aragon: .../ghc-6.8.3/Takusen-0.8.1 > ./Setup build -v Reading parameters from /srv/projects/ctl/franksen/haskell/ghc-6.8.3/Takusen-0.8.1/takusen.buildinfo Creating dist/build (and its parents) Creating dist/build/autogen (and its parents) Preprocessing library Takusen-0.8.1... Building Takusen-0.8.1... Building library... Creating dist/build (and its parents) Creating dist/build (and its parents) /projects/ctl/franksen/usr/bin/ghc -package-name Takusen-0.8.1 --make -hide-all-packages -i -idist/build/autogen -idist/build -i. -Idist/build -I/opt/oracle/product/client/rdbms/demo -odir dist/build -hidir dist/build -stubdir dist/build -package base-3.0.2.0 -package mtl-1.1.0.1 -package time-1.1.2.1 -package old-time-1.0.0.0 -O -XCPP Database.Enumerator Database.Util Database.Oracle.Enumerator Database.Oracle.OCIConstants Database.Oracle.OCIFunctions Database.Stub.Enumerator Control.Exception.MonadIO Foreign.C.UTF8 Database.InternalEnumerator [1 of 9] Compiling Foreign.C.UTF8 ( Foreign/C/UTF8.hs, dist/build/Foreign/C/UTF8.o ) /tmp/ghc18936_0/ghc18936_0.s: Assembler messages: /tmp/ghc18936_0/ghc18936_0.s:1257:0: Error: symbol `base_GHCziBase_Z0T_closure' is already defined I compiled ghc-6.8.3 from source, using ghc-6.8.2 to bootstrap. Any ideas? Cheers Ben From igloo at earth.li Mon Jun 30 11:23:34 2008 From: igloo at earth.li (Ian Lynagh) Date: Mon Jun 30 11:14:47 2008 Subject: [Ticket #2393] Text.PrettyPrint.HughesPJ: Bug fixes, performance improvement In-Reply-To: <1F6084B0-7E94-461D-AA21-B6FEFC089852@gmx.net> References: <755307ED-284E-4DBF-AF8E-2BEEAD64248D@gmail.com> <1F6084B0-7E94-461D-AA21-B6FEFC089852@gmx.net> Message-ID: <20080630152334.GA27407@matrix.chaos.earth.li> On Tue, Jun 24, 2008 at 02:11:34PM +0200, Benedikt Huber wrote: > > I'd like to propose bugfixes, documentation fixes and a performance > improvement for Text.PrettyPrint.HughesPJ. The changes shouldn't > effect the expected behaviour of the PP library. Thanks Benedikt; I've applied your patch. Thanks Ian From dot at dotat.at Mon Jun 30 13:00:04 2008 From: dot at dotat.at (Tony Finch) Date: Mon Jun 30 12:51:18 2008 Subject: GetOpt formatting improvements In-Reply-To: References: <1214776007.7374.19.camel@localhost> <404396ef0806291528v4d92a59cpd78762b0194d37d6@mail.gmail.com> <20080630084028.GA2832@soi.city.ac.uk> Message-ID: On Mon, 30 Jun 2008, Jon Fairbairn wrote: > > Making it read the terminal width is clearly the best option. It should be the maximum of the terminal width and 80 columns. Tony. -- f.anthony.n.finch http://dotat.at/ SHANNON ROCKALL: MAINLY SOUTHERLY 5 TO 7, OCCASIONALLY GALE 8 IN SHANNON, PERHAPS GALE 8 LATER IN ROCKALL, BECOMING CYCLONIC FOR A TIME. ROUGH OR VERY ROUGH. RAIN THEN FAIR. POOR BECOMING GOOD. From jochem at functor.nl Mon Jun 30 13:22:48 2008 From: jochem at functor.nl (Jochem Berndsen) Date: Mon Jun 30 13:14:00 2008 Subject: ANN: Hasim, discrete event simulation in Haskell Message-ID: <1214846568.5442.5.camel@stieltjes.functor.nl> Hi all, I've started a small project to create a library to do discrete event simulation in Haskell. Its website is located at http://huygens.functor.nl/hasim . It uses monads to define a domain-specific language for "actions" of a process. The interested reader is referred to the website. Regards, -- Jochem Berndsen | jochem@functor.nl GPG: 0xE6FABFAB -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/libraries/attachments/20080630/c87334dc/attachment-0001.bin From lemming at henning-thielemann.de Mon Jun 30 15:17:37 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Jun 30 15:08:52 2008 Subject: GetOpt formatting improvements In-Reply-To: References: <1214776007.7374.19.camel@localhost> <404396ef0806291528v4d92a59cpd78762b0194d37d6@mail.gmail.com> <20080630084028.GA2832@soi.city.ac.uk> Message-ID: On Mon, 30 Jun 2008, Tony Finch wrote: > On Mon, 30 Jun 2008, Jon Fairbairn wrote: >> >> Making it read the terminal width is clearly the best option. > > It should be the maximum of the terminal width and 80 columns. Did you mean the _minimum_ ? From allbery at ece.cmu.edu Mon Jun 30 19:52:36 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Jun 30 19:43:49 2008 Subject: GetOpt formatting improvements In-Reply-To: References: <1214776007.7374.19.camel@localhost> <404396ef0806291528v4d92a59cpd78762b0194d37d6@mail.gmail.com> <20080630084028.GA2832@soi.city.ac.uk> Message-ID: <135F486F-F965-4F63-AA50-35A5D0BB90D8@ece.cmu.edu> On 2008 Jun 30, at 15:17, Henning Thielemann wrote: > > On Mon, 30 Jun 2008, Tony Finch wrote: > >> On Mon, 30 Jun 2008, Jon Fairbairn wrote: >>> >>> Making it read the terminal width is clearly the best option. >> >> It should be the maximum of the terminal width and 80 columns. > > Did you mean the _minimum_ ? Maximum, I suspect. As in "don't go nuts trying to fit it into someone's 16x22 pssh". -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH