From dot at dotat.at Tue Jul 1 11:26:18 2008 From: dot at dotat.at (Tony Finch) Date: Tue Jul 1 11:17:31 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, 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_ ? Er yes. Oops! It might make sense to apply a minimum too. Tony. -- f.anthony.n.finch http://dotat.at/ FORTIES CROMARTY FORTH TYNE DOGGER: SOUTHEAST 5 OR 6, OCCASIONALLY 7 FOR A TIME, DECREASING 3 OR 4 LATER IN FORTH, TYNE AND DOGGER. MODERATE, OCCASIONALLY ROUGH FOR A TIME. RAIN FOR A TIME. MODERATE OR GOOD, OCCASIONALLY POOR LATER. From igloo at earth.li Tue Jul 1 11:32:48 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Jul 1 11:23:58 2008 Subject: Takusen build error In-Reply-To: References: Message-ID: <20080701153247.GA5272@matrix.chaos.earth.li> On Mon, Jun 30, 2008 at 02:25:22PM +0200, Benjamin Franksen wrote: > I get a strange error building Takusen (more precisely: the module > Foreign/C/UTF8.hs) with ghc-6.8.3. It says > > /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 Thanks for the report; I've filed a bug here: http://hackage.haskell.org/trac/ghc/ticket/2409 As a workaround, removing the (redundant) uses of () `seq` in Foreign/C/UTF8.hs makes the build go through. Thanks Ian From gwern0 at gmail.com Tue Jul 1 13:57:15 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Tue Jul 1 13:49:01 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: <20080701175715.GA19043@craft> On 2008.06.24 18:29:03 +0400, Bulat Ziganshin scribbled 1.3K characters: > 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 And how would we handle the case where the package is fully maintained, but the maintainer hates Cabal & Hackage and would never give permission? Does the maintainer have eternal veto power over uploads? > 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 As I've indicated elsewhere, I'm a strong supporter of this view. It is better from a long-term view: personal websites are hard to find, they are evanescent, and the opposite view induces great friction and transaction costs. Filtering out packages is easy; but there is no library to undelete information, no way to recover packages purposefully deleted or discouraged from ever being on Hackage. -- gwern MI6 SISDE 36800 Waihopai ple SP4 illuminati FSF cracking rico -------------- 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/20080701/8a6c65b0/attachment.bin From gwern0 at gmail.com Tue Jul 1 14:03:51 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Tue Jul 1 13:55:43 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: <20080701180351.GB19043@craft> On 2008.06.24 10:30:39 +0300, Antti-Juhani Kaijanaho scribbled 1.4K characters: > 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 The alternative is worse: why is it better to have three values ('Specifically unmaintained', 'Maintained by foo', 'not specified either way/omitted field')? At least with the omitted field being significant, users can proceed knowing that if there is a maintainer of a package with omitted maintainer field, they haven't been too diligent about packaging the program. And we already have a situation where omissions are significant. Consider the license: field. If a license isn't specified, it must, legally, be AllRightsReserved. That's the law. -- gwern MI6 SISDE 36800 Waihopai ple SP4 illuminati FSF cracking rico -------------- 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/20080701/81bdcede/attachment.bin From flippa at flippac.org Tue Jul 1 14:07:16 2008 From: flippa at flippac.org (Philippa Cowderoy) Date: Tue Jul 1 13:57:34 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: <20080701175715.GA19043@craft> 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> <20080701175715.GA19043@craft> Message-ID: On Tue, 1 Jul 2008, Gwern Branwen wrote: > > non-maintainers shouldn't upload new versions of maintained packages > > without written ;) maintainer permission. well, as far as maintainer > > answers their letters > > And how would we handle the case where the package is fully maintained, > but the maintainer hates Cabal & Hackage and would never give > permission? Does the maintainer have eternal veto power over uploads? > To the extent it's legal to do so? Upload a package clearly marked as unofficial, with the maintainer field blank. -- flippa@flippac.org Sometimes you gotta fight fire with fire. Most of the time you just get burnt worse though. From gwern0 at gmail.com Tue Jul 1 14:07:46 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Tue Jul 1 13:59:34 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: References: <20080623090559.GA2836@soi.city.ac.uk> Message-ID: <20080701180746.GC19043@craft> On 2008.06.23 20:18:41 -0700, Bryan O'Sullivan scribbled 0.3K characters: > 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. I realize this looks like a trivial discussion, but small things can make big differences - this is one of the primary convictions I've carried away from my Wikipedia experience. The difference in edits between a wiki that forces you to make an account to edit and one that allows anonymous edits can be considerable, even though an account takes like 10 seconds to make (if you've done it before). Similarly, if we force people to explicitly say whether or not something is maintained instead of having a reasonable default when omitted - we are ratcheting up how much of a commitment a Hackage upload represents. People only have so much commitment in them. Supply and demand... -- gwern MI6 SISDE 36800 Waihopai ple SP4 illuminati FSF cracking rico -------------- 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/20080701/db2ba2c6/attachment.bin From alfonso.acosta at gmail.com Tue Jul 1 14:19:55 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Tue Jul 1 14:11:03 2008 Subject: Error accessing data files from package code in Cabal: Unkown symbol Message-ID: <6a7c66fc0807011119k1431ec48pefe0db2b8faa1e24@mail.gmail.com> Hi! I'm working on a library package called ForSyDe. Following Cabal's documentation, I'm using the autogenerated Paths_ForSyDe module in order to access the data files of my library during execution. After installation, the Paths_ForSyDe import seems to be causing an unknown-symbol error whenever I try to compile any code which makes use of the ForSyDe library: " unknown symbol `___stginit_ForSyDezm0zi1_PathszuForSyDe_' " I'm not sure, but it seems that cabal doesn't properly link or install the Paths_ForSyDe module (I tried to include it in the cabal description file to no avail) Any suggestions about how to fix this problem? Thanks in advance, Fons P.S: I'm using Cabal-1.2.3.0 From dons at galois.com Tue Jul 1 14:26:10 2008 From: dons at galois.com (Don Stewart) Date: Tue Jul 1 14:17:24 2008 Subject: Error accessing data files from package code in Cabal: Unkown symbol In-Reply-To: <6a7c66fc0807011119k1431ec48pefe0db2b8faa1e24@mail.gmail.com> References: <6a7c66fc0807011119k1431ec48pefe0db2b8faa1e24@mail.gmail.com> Message-ID: <20080701182610.GE8817@liouville.galois.com> alfonso.acosta: > Hi! > > I'm working on a library package called ForSyDe. > > Following Cabal's documentation, I'm using the autogenerated > Paths_ForSyDe module in order to access the data files of my library > during execution. > > After installation, the Paths_ForSyDe import seems to be causing an > unknown-symbol error whenever I try to compile any code which makes > use of the ForSyDe library: > > " unknown symbol `___stginit_ForSyDezm0zi1_PathszuForSyDe_' " > > I'm not sure, but it seems that cabal doesn't properly link or install > the Paths_ForSyDe module (I tried to include it in the cabal > description file to no avail) > > Any suggestions about how to fix this problem? > > Thanks in advance, Probably you've not listed the Paths_ForSyDe module in your module exports in the .cabal file? From isaacdupree at charter.net Tue Jul 1 14:41:11 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Tue Jul 1 14:32: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> <404396ef0806231506r50320a8h4c95af327da657f@mail.gmail.com> <20080624002844.GB8531@soi.city.ac.uk> <404396ef0806231744m58d5c04fo3d82aa5627cef716@mail.gmail.com> <4860F9D8.5060800@charter.net> <288267141.20080624182903@gmail.com> <20080701175715.GA19043@craft> Message-ID: <486A7A47.6040101@charter.net> Philippa Cowderoy wrote: > On Tue, 1 Jul 2008, Gwern Branwen wrote: > >>> non-maintainers shouldn't upload new versions of maintained packages >>> without written ;) maintainer permission. well, as far as maintainer >>> answers their letters >> And how would we handle the case where the package is fully maintained, >> but the maintainer hates Cabal & Hackage and would never give >> permission? Does the maintainer have eternal veto power over uploads? >> > > To the extent it's legal to do so? Upload a package clearly marked as > unofficial, with the maintainer field blank. If someone wants to put a version on hackage and act as maintainer for it (presumably mostly pulling updates from the "upstream"), should we let them? Although, this situation sounds too hypothetical for me to have any idea how to answer my own question. From antti-juhani at kaijanaho.fi Tue Jul 1 15:08:52 2008 From: antti-juhani at kaijanaho.fi (Antti-Juhani Kaijanaho) Date: Tue Jul 1 15:00:04 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: <20080701180351.GB19043@craft> References: <20080623090559.GA2836@soi.city.ac.uk> <1214257903.15010.1053.camel@localhost> <20080624073038.GG4901@kukkaseppele.kaijanaho.fi> <20080701180351.GB19043@craft> Message-ID: <20080701190852.GU28262@kukkaseppele.kaijanaho.fi> (As I've asked before, please don't send me copies of list emails, unless you have reason to believe I am not subscribed.) On Tue, Jul 01, 2008 at 02:03:51PM -0400, Gwern Branwen wrote: > The alternative is worse: why is it better to have three values > ('Specifically unmaintained', 'Maintained by foo', 'not specified > either way/omitted field')? Arguing by question, hmm? I think I answered that one in my original mail, and you don't give any reason for me to reconsider. > At least with the omitted field being significant, users can proceed > knowing that if there is a maintainer of a package with omitted > maintainer field, they haven't been too diligent about packaging the > program. Failing to check for a trivial error is indiligence? Perhaps. I prefer that such trivial errors be checkable by program - and that requires that a missing value is distinct from a null value. > And we already have a situation where omissions are significant. > Consider the license: field. If a license isn't specified, it must, > legally, be AllRightsReserved. That's the law. You are making an analogy that supports my position, not yours. A missing Cabal license field says "there is no information about license here", not "all rights reserved": thus, the field distinguishes between a missing value and a null value (indeed, if this analogy supported your position, there would be no AllRightsReserved value!). It is true that if the package comes with no license, then you don't have any rights beyond what the law provides you (it does some, but it depends on the jurisdiction). However, there are more ways than just the Cabal license field to specify your license. Personally, I would regard the Cabal license field as informational only and check the package for the actual license statement before doing anything that requires a license. Likewise, I would never release a Cabal package which contains no license statement beyond the Cabal license field. -- 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/20080701/f8ea6792/attachment.bin From alfonso.acosta at gmail.com Tue Jul 1 15:10:21 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Tue Jul 1 15:01:35 2008 Subject: Error accessing data files from package code in Cabal: Unkown symbol In-Reply-To: <20080701182610.GE8817@liouville.galois.com> References: <6a7c66fc0807011119k1431ec48pefe0db2b8faa1e24@mail.gmail.com> <20080701182610.GE8817@liouville.galois.com> Message-ID: <6a7c66fc0807011210k75416948i518ec4ccc81d5b56@mail.gmail.com> On Tue, Jul 1, 2008 at 1:26 PM, Don Stewart wrote: > Probably you've not listed the Paths_ForSyDe module in your module > exports in the .cabal file? Thanks, that was the problem. Since Paths_pkgname is somehow a special module, I stupidly assumed that cabal would take care of exporting it under the hood. I hope that the directory where the Paths_pkgname is included (dist/build/autogen ) doesn't change in the future. Either way, I think it would be a good idea to include a comment about it in the Cabal documentation (http://www.haskell.org/cabal/release/latest/doc/users-guide/authors.html#paths-module ). From gwern0 at gmail.com Tue Jul 1 15:18:57 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Tue Jul 1 15:11:02 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: <486A7A47.6040101@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> <288267141.20080624182903@gmail.com> <20080701175715.GA19043@craft> <486A7A47.6040101@charter.net> Message-ID: <20080701191857.GA3375@craft> On 2008.07.01 14:41:11 -0400, Isaac Dupree scribbled 0.8K characters: > Philippa Cowderoy wrote: >> On Tue, 1 Jul 2008, Gwern Branwen wrote: >> >>>> non-maintainers shouldn't upload new versions of maintained packages >>>> without written ;) maintainer permission. well, as far as maintainer >>>> answers their letters >>> And how would we handle the case where the package is fully >>> maintained, but the maintainer hates Cabal & Hackage and would never >>> give permission? Does the maintainer have eternal veto power over >>> uploads? >>> >> >> To the extent it's legal to do so? Upload a package clearly marked as >> unofficial, with the maintainer field blank. > > If someone wants to put a version on hackage and act as maintainer for > it (presumably mostly pulling updates from the "upstream"), should we > let them? Although, this situation sounds too hypothetical for me to > have any idea how to answer my own question. It's not hypothetical at all. Meachem's Drift stuff is on Hackage, but he certainly hasn't accepted any cabalization patches for it. And I asked in part because I have an experimental cabalization of Darcs which I maintain, and I was thinking of uploading it to Hackage since Darcs 2.0.2 got released - which would be exactly this situation (Roundy has made it clear he opposes cabalization of Darcs, even removing stuff that would make it easier). -- gwern rs9512c Echelon disruption sweep Montenegro TEXTA NSES FBI Phon-e AC -------------- 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/20080701/cde11e28/attachment.bin From ross at soi.city.ac.uk Tue Jul 1 15:20:55 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Jul 1 15:12:16 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> <20080624002844.GB8531@soi.city.ac.uk> <404396ef0806231744m58d5c04fo3d82aa5627cef716@mail.gmail.com> <4860F9D8.5060800@charter.net> <288267141.20080624182903@gmail.com> <20080701175715.GA19043@craft> Message-ID: <20080701192055.GA4943@soi.city.ac.uk> On Tue, Jul 01, 2008 at 07:07:16PM +0100, Philippa Cowderoy wrote: > On Tue, 1 Jul 2008, Gwern Branwen wrote: > > > > non-maintainers shouldn't upload new versions of maintained packages > > > without written ;) maintainer permission. well, as far as maintainer > > > answers their letters > > > > And how would we handle the case where the package is fully maintained, > > but the maintainer hates Cabal & Hackage and would never give > > permission? Does the maintainer have eternal veto power over uploads? > > To the extent it's legal to do so? Upload a package clearly marked as > unofficial, with the maintainer field blank. Under the proposed policy, you'd need to rename the package and change the maintainer field. From allbery at ece.cmu.edu Tue Jul 1 15:21:19 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Jul 1 15:12:43 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: <20080701190852.GU28262@kukkaseppele.kaijanaho.fi> References: <20080623090559.GA2836@soi.city.ac.uk> <1214257903.15010.1053.camel@localhost> <20080624073038.GG4901@kukkaseppele.kaijanaho.fi> <20080701180351.GB19043@craft> <20080701190852.GU28262@kukkaseppele.kaijanaho.fi> Message-ID: <4FF90762-2871-4F0E-88D5-588D281C0D8C@ece.cmu.edu> On 2008 Jul 1, at 15:08, Antti-Juhani Kaijanaho wrote: >> And we already have a situation where omissions are significant. >> Consider the license: field. If a license isn't specified, it must, >> legally, be AllRightsReserved. That's the law. > > A missing Cabal license field says "there is no information about > license here", not "all rights reserved": thus, the field > distinguishes Sadly, the law disagrees. If no license is specified, the license *is* "All Rights Reserved". It doesn't matter what conventions we'd like to apply. -- 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 Tue Jul 1 15:24:49 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Jul 1 15:16:47 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: <4FF90762-2871-4F0E-88D5-588D281C0D8C@ece.cmu.edu> References: <20080623090559.GA2836@soi.city.ac.uk> <1214257903.15010.1053.camel@localhost> <20080624073038.GG4901@kukkaseppele.kaijanaho.fi> <20080701180351.GB19043@craft> <20080701190852.GU28262@kukkaseppele.kaijanaho.fi> <4FF90762-2871-4F0E-88D5-588D281C0D8C@ece.cmu.edu> Message-ID: On Tue, 1 Jul 2008, Brandon S. Allbery KF8NH wrote: > On 2008 Jul 1, at 15:08, Antti-Juhani Kaijanaho wrote: > >>> And we already have a situation where omissions are significant. >>> Consider the license: field. If a license isn't specified, it must, >>> legally, be AllRightsReserved. That's the law. >> >> A missing Cabal license field says "there is no information about >> license here", not "all rights reserved": thus, the field distinguishes > > Sadly, the law disagrees. If no license is specified, the license *is* "All > Rights Reserved". It doesn't matter what conventions we'd like to apply. I think the point was, that there is no law which forces licenses to be specified in the Cabal file, and thus can be anywhere and need not be registered in the Cabal project file. From lemming at henning-thielemann.de Tue Jul 1 15:26:12 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Jul 1 15:18:08 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: <20080701191857.GA3375@craft> 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> <20080701175715.GA19043@craft> <486A7A47.6040101@charter.net> <20080701191857.GA3375@craft> Message-ID: On Tue, 1 Jul 2008, Gwern Branwen wrote: > And I asked in part because I have an experimental cabalization of Darcs > which I maintain, and I was thinking of uploading it to Hackage since > Darcs 2.0.2 got released - which would be exactly this situation (Roundy > has made it clear he opposes cabalization of Darcs, even removing stuff > that would make it easier). Too sad, I thought David was looking for contributors. Wouldn't Cabal simplify contributions? From droundy at darcs.net Tue Jul 1 15:33:57 2008 From: droundy at darcs.net (David Roundy) Date: Tue Jul 1 15:25:53 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: References: <404396ef0806231506r50320a8h4c95af327da657f@mail.gmail.com> <20080624002844.GB8531@soi.city.ac.uk> <404396ef0806231744m58d5c04fo3d82aa5627cef716@mail.gmail.com> <4860F9D8.5060800@charter.net> <288267141.20080624182903@gmail.com> <20080701175715.GA19043@craft> <486A7A47.6040101@charter.net> <20080701191857.GA3375@craft> Message-ID: <20080701193357.GB10093@darcs.net> On Tue, Jul 01, 2008 at 09:26:12PM +0200, Henning Thielemann wrote: > On Tue, 1 Jul 2008, Gwern Branwen wrote: > >And I asked in part because I have an experimental cabalization of Darcs > >which I maintain, and I was thinking of uploading it to Hackage since > >Darcs 2.0.2 got released - which would be exactly this situation (Roundy > >has made it clear he opposes cabalization of Darcs, even removing stuff > >that would make it easier). > > Too sad, I thought David was looking for contributors. Wouldn't Cabal > simplify contributions? No, because it would complicate the build system, so that contributors who wanted to work on darcs would have to deal with autoconf, gnu make *and* cabal. And it would double the number of possible build scenarios, unless we required cabal, in which case it would break compatability with older systems. It's just not worth the maintenance nightmare. David From antti-juhani at kaijanaho.fi Tue Jul 1 16:36:41 2008 From: antti-juhani at kaijanaho.fi (Antti-Juhani Kaijanaho) Date: Tue Jul 1 16:27:51 2008 Subject: agreeing a policy for maintainers and hackageDB In-Reply-To: References: <20080623090559.GA2836@soi.city.ac.uk> <1214257903.15010.1053.camel@localhost> <20080624073038.GG4901@kukkaseppele.kaijanaho.fi> <20080701180351.GB19043@craft> <20080701190852.GU28262@kukkaseppele.kaijanaho.fi> <4FF90762-2871-4F0E-88D5-588D281C0D8C@ece.cmu.edu> Message-ID: <20080701203641.GA5650@kukkaseppele.kaijanaho.fi> On Tue, Jul 01, 2008 at 09:24:49PM +0200, Henning Thielemann wrote: > I think the point was, that there is no law which forces licenses to be > specified in the Cabal file, and thus can be anywhere and need not be > registered in the Cabal project file. That was exactly my point. Thank you. -- Antti-Juhani Kaijanaho, Jyv?skyl?, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ From isaacdupree at charter.net Wed Jul 2 06:40:09 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Wed Jul 2 06:31:30 2008 Subject: GetOpt formatting improvements In-Reply-To: References: <1214776007.7374.19.camel@localhost> <48681D8B.9080008@charter.net> Message-ID: <486B5B09.8040802@charter.net> Brandon S. Allbery KF8NH wrote: > 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). and we say cabal uses a getopt equivalent to this? Yet it doesn't work that way for me, in cabal-install 0.5.1: > cabal fetch -v 3 random cabal: Failed to parse package dependency: "3" > cabal fetch -v3 random Reading installed packages... ("/usr/bin/ghc-pkg",["list"]) Reading available packages... (which, incidentally, I was doing to try to find out why 'cabal fetch' doesn't seem to do anything. And failed miserably. No messages, no new directories in ~/.cabal/packages/hackage.haskell.org/ or in ./ ... Oh wait, fetching uvector works. Maybe it's because GHC comes with random-1.0.0.0 so cabal erroneously thinks it already has the source code that I want to look at, i.e. "for later installation *or study*" as `cabal --help` says?) -Isaac From duncan.coutts at worc.ox.ac.uk Wed Jul 2 08:22:59 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jul 2 08:14:08 2008 Subject: GetOpt formatting improvements In-Reply-To: <486B5B09.8040802@charter.net> References: <1214776007.7374.19.camel@localhost> <48681D8B.9080008@charter.net> <486B5B09.8040802@charter.net> Message-ID: <1215001379.6331.2.camel@localhost> On Wed, 2008-07-02 at 06:40 -0400, Isaac Dupree wrote: > (which, incidentally, I was doing to try to find out why 'cabal fetch' > doesn't seem to do anything. And failed miserably. No messages, no new > directories in ~/.cabal/packages/hackage.haskell.org/ or in ./ ... Oh > wait, fetching uvector works. Maybe it's because GHC comes with > random-1.0.0.0 so cabal erroneously thinks it already has the source > code that I want to look at, i.e. "for later installation *or study*" as > `cabal --help` says?) http://hackage.haskell.org/trac/hackage/ticket/297 "cabal fetch command don't fetch packages those have already been installed" It shouldn't be too hard to fix, so you're most welcome to send in a patch :-) Duncan From duncan.coutts at worc.ox.ac.uk Wed Jul 2 09:57:04 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jul 2 09:48:15 2008 Subject: Error accessing data files from package code in Cabal: Unkown symbol In-Reply-To: <6a7c66fc0807011210k75416948i518ec4ccc81d5b56@mail.gmail.com> References: <6a7c66fc0807011119k1431ec48pefe0db2b8faa1e24@mail.gmail.com> <20080701182610.GE8817@liouville.galois.com> <6a7c66fc0807011210k75416948i518ec4ccc81d5b56@mail.gmail.com> Message-ID: <1215007024.6331.5.camel@localhost> On Tue, 2008-07-01 at 14:10 -0500, Alfonso Acosta wrote: > On Tue, Jul 1, 2008 at 1:26 PM, Don Stewart wrote: > > Probably you've not listed the Paths_ForSyDe module in your module > > exports in the .cabal file? > > Thanks, that was the problem. > > Since Paths_pkgname is somehow a special module, I stupidly assumed > that cabal would take care of exporting it under the hood. I hope that > the directory where the Paths_pkgname is included (dist/build/autogen > ) doesn't change in the future. Do not hard code the path. It can change (via a command line flag). It's not necessary to hard code anything anyway, just using: other-modules: Paths_ForSyDe will work fine (because the $dist/build/autogen path is on the sources search path) I suggest using other-modules rather than exposed-modules because you probably do not need to make that module part of your public api. > Either way, I think it would be a good idea to include a comment about > it in the Cabal documentation > (http://www.haskell.org/cabal/release/latest/doc/users-guide/authors.html#paths-module > ). Right. Duncan From allbery at ece.cmu.edu Wed Jul 2 10:13:17 2008 From: allbery at ece.cmu.edu (Brandon S.Allbery KF8NH) Date: Wed Jul 2 10:04:25 2008 Subject: GetOpt formatting improvements In-Reply-To: <486B5B09.8040802@charter.net> References: <1214776007.7374.19.camel@localhost> <48681D8B.9080008@charter.net> <486B5B09.8040802@charter.net> Message-ID: <56D88718-46C2-4486-9777-905548C08C31@ece.cmu.edu> On 2008 Jul 2, at 6:40, Isaac Dupree wrote: > Brandon S. Allbery KF8NH wrote: >> 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). > > and we say cabal uses a getopt equivalent to this? Yet it doesn't > work that way for me, in We've apparently reinvented the situation that led to AT&T freeing the original getopt() code, I see :) People who roll their own getopt() clone usually miss the corner cases. -- 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 allbery at ece.cmu.edu Wed Jul 2 10:36:54 2008 From: allbery at ece.cmu.edu (Brandon S.Allbery KF8NH) Date: Wed Jul 2 10:28:01 2008 Subject: GetOpt formatting improvements In-Reply-To: <486B5B09.8040802@charter.net> References: <1214776007.7374.19.camel@localhost> <48681D8B.9080008@charter.net> <486B5B09.8040802@charter.net> Message-ID: <332CA231-675E-4F9F-93AB-02EADA5C4EFD@ece.cmu.edu> On 2008 Jul 2, at 6:40, Isaac Dupree wrote: > Brandon S. Allbery KF8NH wrote: >> 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). > > and we say cabal uses a getopt equivalent to this? Yet it doesn't > work that way for me, in We've apparently reinvented the situation that led to AT&T freeing the original getopt() code, I see :) People who roll their own getopt() clone usually miss the corner cases. > cabal-install 0.5.1: > > > cabal fetch -v 3 random > cabal: Failed to parse package dependency: "3" > > cabal fetch -v3 random > Reading installed packages... > ("/usr/bin/ghc-pkg",["list"]) > Reading available packages... > > (which, incidentally, I was doing to try to find out why 'cabal > fetch' doesn't seem to do anything. And failed miserably. No > messages, no new directories in ~/.cabal/packages/ > hackage.haskell.org/ or in ./ ... Oh wait, fetching uvector works. > Maybe it's because GHC comes with random-1.0.0.0 so cabal > erroneously thinks it already has the source code that I want to > look at, i.e. "for later installation *or study*" as `cabal --help` > says?) > > -Isaac -- 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 benjamin.franksen at bessy.de Wed Jul 2 10:43:30 2008 From: benjamin.franksen at bessy.de (Benjamin Franksen) Date: Wed Jul 2 10:34:44 2008 Subject: Takusen build error References: Message-ID: Just a follow-up: I just did a darcs pull on the Takusen repo (which already contains Ian's work-around) and for the first time the cabal install process runs through w/o any problems on our debian linux machine at work (where we have only the Oracle client installed). I can even build and install the docs. Three cheers to Alistair and many thanks for the excellent work on Takusen. Ben From alistair at abayley.org Wed Jul 2 10:56:48 2008 From: alistair at abayley.org (Alistair Bayley) Date: Wed Jul 2 10:47:53 2008 Subject: Takusen build error In-Reply-To: References: Message-ID: <79d7c4980807020756i12277747m77970ca788ec3030@mail.gmail.com> 2008/7/2 Benjamin Franksen : > > I just did a darcs pull on the Takusen repo (which already contains Ian's > work-around) and for the first time the cabal install process runs through > w/o any problems on our debian linux machine at work (where we have only > the Oracle client installed). I can even build and install the docs. Well, I've been pushing these fixes as quickly as I can to get the repo into a nice state for a 0.8.2 release, which we plan to do ASAP. It's nice to get someone to test on non-Windows machines. Thanks. Alistair From benjamin.franksen at bessy.de Wed Jul 2 11:02:52 2008 From: benjamin.franksen at bessy.de (Benjamin Franksen) Date: Wed Jul 2 10:54:08 2008 Subject: Cabal cheers and some feature requests Message-ID: First: Three big cheers to Duncan for his excellent work on cabal, especially the new cabal-install. One feature I think would be uncontroversial is for cabal install to try to build haddock API docs and hscolour'ed sources. Momentarily, I still have to download (or darcs get) the package, unpack and cd into it, and then do cabal configure cabal hscolour cabal haddock cabal install --prefix=my_prefix to have the docs installed, too. Maybe add switches --with-haddock and --with-hscolour to cabal install command? (BTW: what is the trick to get the "source" links into the haddock docs? I remember there was one package I installed where this worked out of the box but I can't find it at the moment.) Another wish on my list is to be able to set defaults for cabal options in my $(HOME)/.cabal/config. Cheers Ben From alfonso.acosta at gmail.com Wed Jul 2 11:50:26 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Wed Jul 2 11:41:32 2008 Subject: Error accessing data files from package code in Cabal: Unkown symbol In-Reply-To: <1215007024.6331.5.camel@localhost> References: <6a7c66fc0807011119k1431ec48pefe0db2b8faa1e24@mail.gmail.com> <20080701182610.GE8817@liouville.galois.com> <6a7c66fc0807011210k75416948i518ec4ccc81d5b56@mail.gmail.com> <1215007024.6331.5.camel@localhost> Message-ID: <6a7c66fc0807020850o3c8a1b3eh6e4312fd6d87779e@mail.gmail.com> On Wed, Jul 2, 2008 at 8:57 AM, Duncan Coutts wrote: > Do not hard code the path. It can change (via a command line flag). > > It's not necessary to hard code anything anyway, just using: > > other-modules: Paths_ForSyDe I tried to avoid doing it, but without adding dist/build/autogen to hs-source-dirs (that is, leaving it as "hs-source-dirs: src") I get the following error: Setup.hs: can't find source for Paths_ForSyDe in ["src"] > I suggest using other-modules rather than exposed-modules because you > probably do not need to make that module part of your public api. Yes, that's what I did. From benjamin.franksen at bessy.de Wed Jul 2 12:00:51 2008 From: benjamin.franksen at bessy.de (Benjamin Franksen) Date: Wed Jul 2 11:52:13 2008 Subject: GetOpt formatting improvements References: <1214776007.7374.19.camel@localhost> <90889fe70806292300j356fec4bx58bed95164d55781@mail.gmail.com> <467162F8-C5DC-4771-898A-74EFCFA8B8EF@ece.cmu.edu> Message-ID: Brandon S. Allbery KF8NH wrote: > 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 I agree with others that 79 is better default. (Btw, finding out the terminal width is a IO action, so we can't do that. I like it very much that the API for GetOpt is pure.) Anyway, the maximum output width, as well as a maximum indentation for the option descriptions should be arguments to (new, additional) functions getOptExt and usageInfoExt, with the old getOpt and usageInfo being defined in terms of the new variants. >>> 2. use less padding between columns Yes, but add a comma, see below. >>> 3. omit the args on short options when there is also a >>> corresponding long option I think this is an excellent idea. >> 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. Whitespace shouldn't matter for parsing usage output, so we can deviate from GNU here. I think one space is enough. > Short options are separated from long by ", ", Here we should follow GNU, I think. > and that column is left > empty if there is no corresponding short option. This looks nice IMO (and we agree with GNU already). > 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. It makes sense to have a _maximum_ indentation for the description, otherwise one very long option name completely ruins the layout. Following GNU (de facto) standard makes sense here. > 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) Which is a bug, IMO, we should not copy that. Cheers Ben From ndmitchell at gmail.com Wed Jul 2 12:07:21 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Jul 2 11:58:27 2008 Subject: GetOpt formatting improvements In-Reply-To: References: <1214776007.7374.19.camel@localhost> <90889fe70806292300j356fec4bx58bed95164d55781@mail.gmail.com> <467162F8-C5DC-4771-898A-74EFCFA8B8EF@ece.cmu.edu> Message-ID: <404396ef0807020907j39e47aecu72ef8cb60667e5b8@mail.gmail.com> Hi > Anyway, the maximum output width, as well as a maximum indentation for the > option descriptions should be arguments to (new, additional) functions > getOptExt and usageInfoExt, with the old getOpt and usageInfo being defined > in terms of the new variants. I think thats a really bad idea. We want options that work and do the sensible thing. When would a user want to set these options to different values? Without a use case, and a potential user, these extra variants are a waste of hard-drive space. Thanks Neil From benjamin.franksen at bessy.de Wed Jul 2 12:08:52 2008 From: benjamin.franksen at bessy.de (Benjamin Franksen) Date: Wed Jul 2 12:00:08 2008 Subject: Package collections-0.3 vanished from hackage Message-ID: I am certain that once there was a package named collections-0.3 on the hackage server. It is gone. I managed to get the darcs version form http://code.haskell.org/collections, so this is not a show-stopper for me, but still things like that should not happen, IMO. Cheers Ben From duncan.coutts at worc.ox.ac.uk Wed Jul 2 12:17:30 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jul 2 12:08:38 2008 Subject: Error accessing data files from package code in Cabal: Unkown symbol In-Reply-To: <6a7c66fc0807020850o3c8a1b3eh6e4312fd6d87779e@mail.gmail.com> References: <6a7c66fc0807011119k1431ec48pefe0db2b8faa1e24@mail.gmail.com> <20080701182610.GE8817@liouville.galois.com> <6a7c66fc0807011210k75416948i518ec4ccc81d5b56@mail.gmail.com> <1215007024.6331.5.camel@localhost> <6a7c66fc0807020850o3c8a1b3eh6e4312fd6d87779e@mail.gmail.com> Message-ID: <1215015450.6331.9.camel@localhost> On Wed, 2008-07-02 at 10:50 -0500, Alfonso Acosta wrote: > On Wed, Jul 2, 2008 at 8:57 AM, Duncan Coutts > wrote: > > Do not hard code the path. It can change (via a command line flag). > > > > It's not necessary to hard code anything anyway, just using: > > > > other-modules: Paths_ForSyDe > > I tried to avoid doing it, but without adding dist/build/autogen to > hs-source-dirs (that is, leaving it as "hs-source-dirs: src") I get > the following error: > > Setup.hs: can't find source for Paths_ForSyDe in ["src"] Ah, sorry, that bug was only fixed in Cabal-1.4 so yes it will not work in Cabal-1.2.x. The reason not that many people have run into this issue is that typically it is executables not libraries that use data files and thus use the Paths_pkgname module and for executables it's possible to get away without listing all modules in the extra/other-modules fields. Duncan From duncan.coutts at worc.ox.ac.uk Wed Jul 2 12:29:27 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jul 2 12:20:33 2008 Subject: Cabal cheers and some feature requests In-Reply-To: References: Message-ID: <1215016167.6331.19.camel@localhost> On Wed, 2008-07-02 at 17:02 +0200, Benjamin Franksen wrote: > First: Three big cheers to Duncan for his excellent work on cabal, > especially the new cabal-install. Thanks :-). There are lots of other contributors of course, not just me. Remember the best place for feature requests is in the hackage trac: http://hackage.haskell.org/trac/ commenting on a ticket and adding yourself to the 'cc' list counts as a vote for the ticket. It really helps us to prioritise development work. > One feature I think would be uncontroversial is for cabal install to try to > build haddock API docs and hscolour'ed sources. Momentarily, I still have > to download (or darcs get) the package, unpack and cd into it, and then do > > cabal configure > cabal hscolour > cabal haddock > cabal install --prefix=my_prefix > > to have the docs installed, too. > > Maybe add switches --with-haddock and --with-hscolour to cabal install > command? http://hackage.haskell.org/trac/hackage/ticket/206 Currently the #1 most commonly requested feature. Please comment on the ticket. It's not clear exactly how this feature should work, ie how to specify the flags. Implementing this should be trivial once we've agreed how the interaction will work. > (BTW: what is the trick to get the "source" links into the haddock docs? I > remember there was one package I installed where this worked out of the box > but I can't find it at the moment.) See $ cabal haddock --help --hyperlink-source Hyperlink the documentation to the source code (using HsColour) > Another wish on my list is to be able to set defaults for cabal options in > my $(HOME)/.cabal/config. Currently you can do this for a subset of the flags (like prefix, profiling) and we do intend to extend it to the full set. http://hackage.haskell.org/trac/hackage/ticket/223 Duncan From benjamin.franksen at bessy.de Wed Jul 2 12:37:14 2008 From: benjamin.franksen at bessy.de (Benjamin Franksen) Date: Wed Jul 2 12:28:32 2008 Subject: GetOpt formatting improvements References: <1214776007.7374.19.camel@localhost> <90889fe70806292300j356fec4bx58bed95164d55781@mail.gmail.com> <467162F8-C5DC-4771-898A-74EFCFA8B8EF@ece.cmu.edu> <404396ef0807020907j39e47aecu72ef8cb60667e5b8@mail.gmail.com> Message-ID: Neil Mitchell wrote: >> Anyway, the maximum output width, as well as a maximum indentation for >> the option descriptions should be arguments to (new, additional) >> functions getOptExt and usageInfoExt, with the old getOpt and usageInfo >> being defined in terms of the new variants. > > I think thats a really bad idea. We want options that work and do the > sensible thing. When would a user want to set these options to > different values? Without a use case, and a potential user, these > extra variants are a waste of hard-drive space. I thought the use case I had in mind was apparent from the context: finding out the terminal width and then setting the wrap-width accordingly. And the max. description indentation could be set as a percentage of the terminal width. This is all quite similar to what pretty printing libs allow. Generally I think that hard-coding numerical constants in code is nearly always a very bad idea. Much worse than adding a few 100 bytes to the libraries. Cheers Ben From ndmitchell at gmail.com Wed Jul 2 12:42:25 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Jul 2 12:33:31 2008 Subject: GetOpt formatting improvements In-Reply-To: References: <1214776007.7374.19.camel@localhost> <90889fe70806292300j356fec4bx58bed95164d55781@mail.gmail.com> <467162F8-C5DC-4771-898A-74EFCFA8B8EF@ece.cmu.edu> <404396ef0807020907j39e47aecu72ef8cb60667e5b8@mail.gmail.com> Message-ID: <404396ef0807020942r4a607b21j276740bc626d7f70@mail.gmail.com> Hi > > I think thats a really bad idea. We want options that work and do the > > sensible thing. When would a user want to set these options to > > different values? Without a use case, and a potential user, these > > extra variants are a waste of hard-drive space. > > I thought the use case I had in mind was apparent from the context: finding > out the terminal width and then setting the wrap-width accordingly. And the > max. description indentation could be set as a percentage of the terminal > width. This is all quite similar to what pretty printing libs allow. I'd suggest a much better idea would be to have one function which did all this, in the IO Monad. Some sort of showTheGetOptHelpWithTheRightWidth :: IO (). Before adding a function I think its important to ask "what will this function be used for" - if there are no particularly good answers, then its best not to add it. If it happens to be a general case of something where everyone will want a specific case then the specific case seems more appealing. > Generally I think that hard-coding numerical constants in code is nearly > always a very bad idea. Agreed :-) Thanks Neil From dons at galois.com Wed Jul 2 13:11:11 2008 From: dons at galois.com (Don Stewart) Date: Wed Jul 2 13:02:41 2008 Subject: Package collections-0.3 vanished from hackage In-Reply-To: References: Message-ID: <20080702171111.GA26461@liouville.galois.com> benjamin.franksen: > I am certain that once there was a package named collections-0.3 on the > hackage server. It is gone. > > I managed to get the darcs version form http://code.haskell.org/collections, > so this is not a show-stopper for me, but still things like that should not > happen, IMO. Yes, collections seems to have disappeared. Was it part of the gwern forks, I thought that only referred to: collections-api 0.4 collections-avl 0.4 collections-base-instances 0.4 collections-rangedsets-instances 0.4 Not collections 0.3, which was uploaded by Jean Philippe-Bernardy in Mar 2007, http://209.85.173.104/search?q=cache:2pvRKx97NcwJ:hackage.haskell.org/cgi-bin/hackage-scripts/package/collections-0.3+collections+site:hackage.haskell.org/cgi-bin/hackage-scripts/package&hl=en&ct=clnk&cd=2&gl=uk -- Don From ross at soi.city.ac.uk Wed Jul 2 13:34:48 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Jul 2 13:25:59 2008 Subject: Package collections-0.3 vanished from hackage In-Reply-To: <20080702171111.GA26461@liouville.galois.com> References: <20080702171111.GA26461@liouville.galois.com> Message-ID: <20080702173448.GA3572@soi.city.ac.uk> On Wed, Jul 02, 2008 at 10:11:11AM -0700, Don Stewart wrote: > benjamin.franksen: > > I am certain that once there was a package named collections-0.3 on the > > hackage server. It is gone. > > > > I managed to get the darcs version form http://code.haskell.org/collections, > > so this is not a show-stopper for me, but still things like that should not > > happen, IMO. > > Yes, collections seems to have disappeared. Was it part of > the gwern forks, I thought that only referred to: > > collections-api 0.4 > collections-avl 0.4 > collections-base-instances 0.4 > collections-rangedsets-instances 0.4 > > Not collections 0.3, which was uploaded by Jean Philippe-Bernardy > in Mar 2007, > > http://209.85.173.104/search?q=cache:2pvRKx97NcwJ:hackage.haskell.org/cgi-bin/hackage-scripts/package/collections-0.3+collections+site:hackage.haskell.org/cgi-bin/hackage-scripts/package&hl=en&ct=clnk&cd=2&gl=uk Sorry, I shot an innocent bystander. Resurrected now. From iavor.diatchki at gmail.com Wed Jul 2 17:19:20 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed Jul 2 17:10:28 2008 Subject: Faster graph SCCs Message-ID: <5ab17e790807021419n35eaab37jb9bd88f0d459bd68@mail.gmail.com> Hi, I have implemented Tarjan's algorithm for computing the strongly connected components of a graph. It is considerably faster then what's available in the "containers" package for larger graphs (see the attached picture). It would be nice to replace the existing implementation in the containers package, but I though that I'd check with the mailing list before I do this. If you want to try it out, I have put the code on hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/GraphSCC -Iavor -------------- next part -------------- A non-text attachment was scrubbed... Name: diagram.png Type: image/png Size: 3920 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20080702/28b32c60/diagram-0001.png From ndmitchell at gmail.com Wed Jul 2 17:24:58 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Jul 2 17:16:04 2008 Subject: Faster graph SCCs In-Reply-To: <5ab17e790807021419n35eaab37jb9bd88f0d459bd68@mail.gmail.com> References: <5ab17e790807021419n35eaab37jb9bd88f0d459bd68@mail.gmail.com> Message-ID: <404396ef0807021424i4a398221h305dd84fd194837b@mail.gmail.com> Hi Iavor, > connected components of a graph. It is considerably faster then > what's available in the "containers" package for larger graphs (see > the attached picture). Is it slower in any circumstances? If so, by how much? However, that graph makes it look like a fairly simple choice... Thanks Neil From wnoise at ofb.net Wed Jul 2 17:37:36 2008 From: wnoise at ofb.net (Aaron Denney) Date: Wed Jul 2 17:28:58 2008 Subject: GetOpt formatting improvements References: <1214776007.7374.19.camel@localhost> <90889fe70806292300j356fec4bx58bed95164d55781@mail.gmail.com> <467162F8-C5DC-4771-898A-74EFCFA8B8EF@ece.cmu.edu> <404396ef0807020907j39e47aecu72ef8cb60667e5b8@mail.gmail.com> <404396ef0807020942r4a607b21j276740bc626d7f70@mail.gmail.com> Message-ID: On 2008-07-02, Neil Mitchell wrote: > Hi > >> > I think thats a really bad idea. We want options that work and do the >> > sensible thing. When would a user want to set these options to >> > different values? Without a use case, and a potential user, these >> > extra variants are a waste of hard-drive space. >> >> I thought the use case I had in mind was apparent from the context: finding >> out the terminal width and then setting the wrap-width accordingly. And the >> max. description indentation could be set as a percentage of the terminal >> width. This is all quite similar to what pretty printing libs allow. > > I'd suggest a much better idea would be to have one function which did > all this, in the IO Monad. Some sort of > showTheGetOptHelpWithTheRightWidth :: IO (). Before adding a function > I think its important to ask "what will this function be used for" - > if there are no particularly good answers, then its best not to add > it. If it happens to be a general case of something where everyone > will want a specific case then the specific case seems more appealing. Everyone? No one will want to ever put it into a gui widget with a a width that's not 80? Composability and flexibility are cheap in this case. -- Aaron Denney -><- From dons at galois.com Wed Jul 2 18:02:34 2008 From: dons at galois.com (Don Stewart) Date: Wed Jul 2 17:53:43 2008 Subject: Faster graph SCCs In-Reply-To: <5ab17e790807021419n35eaab37jb9bd88f0d459bd68@mail.gmail.com> References: <5ab17e790807021419n35eaab37jb9bd88f0d459bd68@mail.gmail.com> Message-ID: <20080702220234.GA7303@liouville.galois.com> iavor.diatchki: > Hi, > I have implemented Tarjan's algorithm for computing the strongly > connected components of a graph. It is considerably faster then > what's available in the "containers" package for larger graphs (see > the attached picture). It would be nice to replace the existing > implementation in the containers package, but I though that I'd check > with the mailing list before I do this. If you want to try it out, I > have put the code on hackage: > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/GraphSCC > > -Iavor +1 The Data.Graph library needs some love, and these numbers are fairly awesome. -- Don From ben.franksen at online.de Wed Jul 2 19:26:49 2008 From: ben.franksen at online.de (Ben Franksen) Date: Wed Jul 2 19:18:02 2008 Subject: Cabal cheers and some feature requests References: <1215016167.6331.19.camel@localhost> Message-ID: Duncan Coutts wrote: > On Wed, 2008-07-02 at 17:02 +0200, Benjamin Franksen wrote: > Remember the best place for feature requests is in the hackage trac: > > http://hackage.haskell.org/trac/ > > commenting on a ticket and adding yourself to the 'cc' list counts as a > vote for the ticket. It really helps us to prioritise development work. > >> One feature I think would be uncontroversial is for cabal install to try >> to build haddock API docs and hscolour'ed sources. Momentarily, I still >> have to download (or darcs get) the package, unpack and cd into it, and >> then do >> >> cabal configure >> cabal hscolour >> cabal haddock >> cabal install --prefix=my_prefix >> >> to have the docs installed, too. >> >> Maybe add switches --with-haddock and --with-hscolour to cabal install >> command? > > http://hackage.haskell.org/trac/hackage/ticket/206 > > Currently the #1 most commonly requested feature. > > Please comment on the ticket. It's not clear exactly how this feature > should work, ie how to specify the flags. Implementing this should be > trivial once we've agreed how the interaction will work. I'll be a good boy and do that ;) >> (BTW: what is the trick to get the "source" links into the haddock docs? >> I remember there was one package I installed where this worked out of the >> box but I can't find it at the moment.) > > See $ cabal haddock --help > > --hyperlink-source Hyperlink the documentation to the source code > (using HsColour) Oh, how simple. And how --ahem-- trivial to find out. >> Another wish on my list is to be able to set defaults for cabal options >> in my $(HOME)/.cabal/config. > > Currently you can do this for a subset of the flags (like prefix, > profiling) and we do intend to extend it to the full set. > > http://hackage.haskell.org/trac/hackage/ticket/223 Thanks Ben From ben.franksen at online.de Wed Jul 2 19:29:27 2008 From: ben.franksen at online.de (Ben Franksen) Date: Wed Jul 2 19:21:07 2008 Subject: Package collections-0.3 vanished from hackage References: <20080702171111.GA26461@liouville.galois.com> <20080702173448.GA3572@soi.city.ac.uk> Message-ID: Ross Paterson wrote: > On Wed, Jul 02, 2008 at 10:11:11AM -0700, Don Stewart wrote: >> benjamin.franksen: >> > I am certain that once there was a package named collections-0.3 on the >> > hackage server. It is gone. > > Sorry, I shot an innocent bystander. Resurrected now. Thanks Ben From v.dijk.bas at gmail.com Thu Jul 3 14:56:19 2008 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Thu Jul 3 14:47:25 2008 Subject: hscurses under wrong category Message-ID: Hello, I noticed that the hscurses package[1] is listed under category "User-interface" while all other user interface packages are listed under "User Interfaces". Could someone please release hscurses under the "User Interfaces" category and remove the current one? That will make it more consistent. Thanks Bas [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hscurses From dons at galois.com Thu Jul 3 15:00:06 2008 From: dons at galois.com (Don Stewart) Date: Thu Jul 3 14:51:58 2008 Subject: hscurses under wrong category In-Reply-To: References: Message-ID: <20080703190006.GE12370@liouville.galois.com> v.dijk.bas: > Hello, > > I noticed that the hscurses package[1] is listed under category > "User-interface" while all other user interface packages are listed > under "User Interfaces". > > Could someone please release hscurses under the "User Interfaces" > category and remove the current one? That will make it more > consistent. > > Thanks In general we need a way for trusted users to tag and categorise packages. Restricting uploaded categories would also help in the ontology sprawl. From lemming at henning-thielemann.de Thu Jul 3 15:12:58 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Jul 3 15:04:01 2008 Subject: hscurses under wrong category In-Reply-To: <20080703190006.GE12370@liouville.galois.com> References: <20080703190006.GE12370@liouville.galois.com> Message-ID: On Thu, 3 Jul 2008, Don Stewart wrote: > v.dijk.bas: >> Hello, >> >> I noticed that the hscurses package[1] is listed under category >> "User-interface" while all other user interface packages are listed >> under "User Interfaces". >> >> Could someone please release hscurses under the "User Interfaces" >> category and remove the current one? That will make it more >> consistent. > > In general we need a way for trusted users to tag and categorise > packages. Restricting uploaded categories would also help in the > ontology sprawl. I suggested that introduction of new categories should not be restricted, but at least a warning and a question should be raised if you introduce a new category, because it may only be the difference between "User Interface" and "User-Interface". The downside is, that introducing new categories in order to place "unique" packages is too tempting. From iavor.diatchki at gmail.com Thu Jul 3 19:15:36 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Thu Jul 3 19:06:38 2008 Subject: Faster graph SCCs In-Reply-To: <404396ef0807021424i4a398221h305dd84fd194837b@mail.gmail.com> References: <5ab17e790807021419n35eaab37jb9bd88f0d459bd68@mail.gmail.com> <404396ef0807021424i4a398221h305dd84fd194837b@mail.gmail.com> Message-ID: <5ab17e790807031615o77398f7ej294edf1c1fd18048@mail.gmail.com> Hi, I don't know of any examples when it is slower. -Iavor On Wed, Jul 2, 2008 at 2:24 PM, Neil Mitchell wrote: > Hi Iavor, > >> connected components of a graph. It is considerably faster then >> what's available in the "containers" package for larger graphs (see >> the attached picture). > > Is it slower in any circumstances? If so, by how much? > > However, that graph makes it look like a fairly simple choice... > > Thanks > > Neil > From naur at post11.tele.dk Fri Jul 4 09:13:54 2008 From: naur at post11.tele.dk (Thorkil Naur) Date: Fri Jul 4 09:08:38 2008 Subject: [Ticket #2393] Text.PrettyPrint.HughesPJ: Bug fixes, performance improvement In-Reply-To: <4863E296.6090002@gmx.net> References: <755307ED-284E-4DBF-AF8E-2BEEAD64248D@gmail.com> <200806252158.27087.naur@post11.tele.dk> <4863E296.6090002@gmx.net> Message-ID: <200807041513.56130.naur@post11.tele.dk> Hello Benedikt, On Thursday 26 June 2008 20:40, Benedikt Huber wrote: > 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, I suggest to add documentation as suggested by Simon PJ and then close it. > ... > #1176 propably fixed. I don't think so: The infinite loop is gone, but the GHC version of the pretty-printing library still has the error reported as #1337 against the external library (see the comments that I added to #1176.). > > 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 $*$. > ... > > 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 ? This looks like the same thing, yes, so a correstion to the GHC version of the pretty-printing library like the one you supplied for #1337 seems called for. > ... > As you seem to know the pretty printer library well, it would be great > if you could comment on the revised specification of fill. The new specification certainly explained things for me that I had not understood earlier, so it is definitely an improvement. > ... Best regards Thorkil From igloo at earth.li Fri Jul 4 09:29:24 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Jul 4 09:20:24 2008 Subject: Proposal: Extensible exceptions Message-ID: <20080704132924.GA3983@matrix.chaos.earth.li> Hi all, This is a proposal to replace the current exception mechanism in the base library with extensible exceptions. It also reimplements the existing exceptions on top of extensible exceptions, for legacy applications. Proposed deadline: 25th July. http://hackage.haskell.org/trac/ghc/ticket/2419 === What are extensible exceptions? Simon's extensible extensions paper is very easy to read, and describes the problems and proposed solution very well: http://www.haskell.org/~simonmar/papers/ext-exceptions.pdf I won't try to reproduce everything the paper says here, but here is the list of what we want extracted from it: * A hierarchy of exception types, such that a particular catch can choose to catch only exceptions that belong to a particular subclass and re-throw all others. * A way to add new exception types at any point in the hierarchy from library or program code. * The boilerplate code required to add a new type to the exception hierarchy should be minimal. * Exceptions should be thrown and caught using the same primitives, regardless of the types involved. I heartily recommend having a read through of the paper. === Patches and examples The patches are here: http://darcs.haskell.org/ext-excep/ I've attached Examples.hs, which gives some examples of using it. The patches aren't polished; if this proposal is accepted then there is some more work to do, moving things around inside the base package to simplify the dependencies, and to maximise the amount of code that can be shared between all the impls. There's also some GHC-specific fiddling to be done, to make GHC.TopHandler use the new exceptions. This can all be done without further library proposals, though. Also, currently it derives Data.Typeable, which is unportable, but we can easily work around that. The only extensions that I don't think that we can do without are ExistentialQuantification and Rank2Types. DeriveDataTypeable makes the implementation easier, and DeriveDataTypeable and PatternSignatures make using it easier. === Library function differences As far as the library functions are concerned, here are the main differences: The old and new types for catch are: Old: catch :: IO a -> (Exception -> IO a) -> IO a New: catch :: Exception e => IO a -> (e -> IO a) -> IO a i.e. catch can now catch any type of exception; we don't have to force all the different types of extension into one fixed datatype. All the other exception functions are similarly changed to handle any type of extension, e.g. we now have try :: Exception e => IO a -> IO (Either e a) Now that you can write handlers for different exception types, you might want to catch multiple different types at the same point. You can use catches for this. For example, the OldException module needs to catch all the new exception types and put them into the old Exception type, so that the legacy handler can be run on them. It looks like this: catch :: IO a -> (Exception -> IO a) -> IO a catch io handler = io `catches` [Handler (\e -> handler e), Handler (\exc -> handler (ArithException exc)), Handler (\exc -> handler (ArrayException exc)), ...] where the first Handler deals with exceptions of type Exception, the second those of type ArithException, and so on. If you want to catch all exceptions, e.g. if you want to cleanup and rethrow the exception, or just print the exception at the top-level, you can use the new function catchAny: catchAny :: IO a -> (forall e . Exception e => e -> IO a) -> IO a You can happily write `catchAny` \e -> print e where `catch` \e -> print e would give you an ambiguous type variable error. There's also ignoreExceptions :: IO () -> IO () which can be used instead of try for things like ignoreExceptions (hClose h) (where we don't look at the result, so the exception type would be ambiguous if we used try). (I'm not sure if this is the best name for this function). All the build failures I've seen with the new exceptions library have been cases where you need to change a "catch" to "catchAny", "try" to "ignoreExceptions", or occassionally a different function, e.g. "bracket" or "handle", is used to handle any extension, so adding a type signature involving the SomeException type solves the problem. The old interface is available in Control.OldException. Currently it doesn't catch exceptions that don't fit into the old Exception type; we could catch them, show them and treat them as user errors, but then the exception has changed if it gets rethrown. Thanks Ian -------------- next part -------------- A non-text attachment was scrubbed... Name: Examples.hs Type: text/x-haskell Size: 3432 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20080704/f6e52b2b/Examples.bin From marlowsd at gmail.com Fri Jul 4 09:56:06 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Jul 4 09:47:13 2008 Subject: Proposal: Extensible exceptions In-Reply-To: <20080704132924.GA3983@matrix.chaos.earth.li> References: <20080704132924.GA3983@matrix.chaos.earth.li> Message-ID: <486E2BF6.2060203@gmail.com> Ian Lynagh wrote: > This is a proposal to replace the current exception mechanism in the > base library with extensible exceptions. I'm generally in favour of this (of course) ... > There's also > ignoreExceptions :: IO () -> IO () > which can be used instead of try for things like > ignoreExceptions (hClose h) > (where we don't look at the result, so the exception type would be > ambiguous if we used try). (I'm not sure if this is the best name for > this function). But I think we should omit ignoreExceptions completely, or at least strongly discourage its use. (I mentioned this to Ian privately, he asked me to bring it up on the list). The problem with discarding *any* exception is that it breaks modularity: for example, things like System.Timeout rely on being able to interrupt any computation by using a private exception. Ignoring exceptions should always be limited to a particular class of exceptions that you want to ignore. Existing uses of ignoreExceptions should be scrutinised very carefully. In fact, this applies to catchAny too. It should come with a strong warning, and a suggestion that any unrecognised exceptions should be re-thrown. Most uses of catchAny are to implement an on-error action anyway, I think this ought to be provided as a combinator. We have bracketOnError, but perhaps we should also have onException :: IO a -> IO b -> IO a Cheers, Simon From haskell at list.mightyreason.com Fri Jul 4 10:52:32 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Fri Jul 4 10:43:39 2008 Subject: Proposal: Extensible exceptions In-Reply-To: <20080704132924.GA3983@matrix.chaos.earth.li> References: <20080704132924.GA3983@matrix.chaos.earth.li> Message-ID: <486E3930.5040807@list.mightyreason.com> Ian Lynagh wrote: > === Library function differences > > As far as the library functions are concerned, here are the main > differences: > > The old and new types for catch are: > Old: catch :: IO a -> (Exception -> IO a) -> IO a > New: catch :: Exception e => IO a -> (e -> IO a) -> IO a > i.e. catch can now catch any type of exception; we don't have to force > all the different types of extension into one fixed datatype. Is there any sane way to allow extending or building equivalents to these for MonadIO? -- Chris From gale at sefer.org Fri Jul 4 10:54:11 2008 From: gale at sefer.org (Yitzchak Gale) Date: Fri Jul 4 10:45:10 2008 Subject: Proposal: Extensible exceptions In-Reply-To: <20080704132924.GA3983@matrix.chaos.earth.li> References: <20080704132924.GA3983@matrix.chaos.earth.li> Message-ID: <2608b8a80807040754s3326fa87nc7700c253ed76425@mail.gmail.com> Ian Lynagh wrote: > This is a proposal to replace the current exception mechanism in the > base library with extensible exceptions... How does this affect integration between IO exceptions and pure exceptions, in particular Control.Monad.Error from mtl? That is already a bit tricky, but doable. Does this make it worse? At the very least, we should take this opportunity to create Error instances for the standard exceptions, and make sure that the extension mechanism includes an easy way to add compatible Error instances for new exceptions. Besides the mechanism itself, the obvious question is how to do this without making a mess out of the package dependency hierarchy. Thanks, Yitz From bulat.ziganshin at gmail.com Fri Jul 4 13:17:47 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Jul 4 13:18:29 2008 Subject: Proposal: Extensible exceptions In-Reply-To: <20080704132924.GA3983@matrix.chaos.earth.li> References: <20080704132924.GA3983@matrix.chaos.earth.li> Message-ID: <1334190008.20080704211747@gmail.com> Hello Ian, Friday, July 4, 2008, 5:29:24 PM, you wrote: > This is a proposal to replace the current exception mechanism in the > base library with extensible exceptions. extensible exceptions, records and syntax are my favorite missing-in-haskell-garden pets, so my +1000 syntax to defining new exceptions is a bit too fat, but it's probably impossible to use something more direct and consistent like it's done in OOP languages? also, are your examples cover all the possible scenarios of using exceptions? you may consider it as tutorial on "New Exceptions" :) is it planned to be included in 6.10? how it will work with legacy code, in particular libraries developed with old base in mind? how mixed code (throwing/catching exceptions in old and new styles) will work together? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From shelarcy at gmail.com Fri Jul 4 14:00:53 2008 From: shelarcy at gmail.com (shelarcy) Date: Fri Jul 4 13:52:13 2008 Subject: Proposal: Extensible exceptions In-Reply-To: <20080704132924.GA3983@matrix.chaos.earth.li> References: <20080704132924.GA3983@matrix.chaos.earth.li> Message-ID: On Fri, 04 Jul 2008 22:29:24 +0900, Ian Lynagh wrote: > This is a proposal to replace the current exception mechanism in the > base library with extensible exceptions. I like this change. > The patches are here: > http://darcs.haskell.org/ext-excep/ > I've attached Examples.hs, which gives some examples of using it. But It seems that current patches doesn't change GHC.Conc module's catchSTM type. I think we should change that type, too. catchSTM :: Exception e => STM a -> (e -> STM a) -> STM a But One problem is that these changes also affect stm package's interface. We need following functions, and old interface same as IO type catching functions, for usability. catchesSTM :: STM a -> [Handler a] -> STM a catchSTMAny :: STM a -> (forall e . Exception e => e -> STM a) -> STM a ... Do you think we should have another proposal to change catchSTM type, after accepting this proposal? Best Regards, -- shelarcy http://page.freett.com/shelarcy/ From judah.jacobson at gmail.com Fri Jul 4 14:12:16 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Fri Jul 4 14:03:16 2008 Subject: Proposal: Extensible exceptions In-Reply-To: <486E3930.5040807@list.mightyreason.com> References: <20080704132924.GA3983@matrix.chaos.earth.li> <486E3930.5040807@list.mightyreason.com> Message-ID: <6d74b0d20807041112k2926d5f4ycc91c530180116d7@mail.gmail.com> On Fri, Jul 4, 2008 at 10:52 AM, Chris Kuklewicz wrote: > Ian Lynagh wrote: >> >> The old and new types for catch are: >> Old: catch :: IO a -> (Exception -> IO a) -> IO a >> New: catch :: Exception e => IO a -> (e -> IO a) -> IO a >> i.e. catch can now catch any type of exception; we don't have to force >> all the different types of extension into one fixed datatype. > > Is there any sane way to allow extending or building equivalents to these > for MonadIO? > MonadIO currently isn't enough to implement catch. There's been discussion of this in the past, though; for an example solution, see the following module from the haskell-prime wiki: http://hackage.haskell.org/trac/haskell-prime/attachment/ticket/110/Exception.txt I had been thinking of proposing that a Control.Monad.Exception module be added to the mtl package, but any discussion on this subject should probably wait until the extensible exceptions API is nailed down. -Judah From igloo at earth.li Fri Jul 4 14:52:21 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Jul 4 14:43:21 2008 Subject: Proposal: Extensible exceptions In-Reply-To: <486E2BF6.2060203@gmail.com> References: <20080704132924.GA3983@matrix.chaos.earth.li> <486E2BF6.2060203@gmail.com> Message-ID: <20080704185221.GA32684@matrix.chaos.earth.li> On Fri, Jul 04, 2008 at 02:56:06PM +0100, Simon Marlow wrote: > Ian Lynagh wrote: > > >There's also > > ignoreExceptions :: IO () -> IO () > >which can be used instead of try for things like > > ignoreExceptions (hClose h) > >(where we don't look at the result, so the exception type would be > >ambiguous if we used try). (I'm not sure if this is the best name for > >this function). > > But I think we should omit ignoreExceptions completely, or at least > strongly discourage its use. (I mentioned this to Ian privately, he asked > me to bring it up on the list). > > The problem with discarding *any* exception is that it breaks modularity: > for example, things like System.Timeout rely on being able to interrupt any > computation by using a private exception. Ignoring exceptions should > always be limited to a particular class of exceptions that you want to > ignore. Existing uses of ignoreExceptions should be scrutinised very > carefully. Hmm, I agree, but if people are doing it already (using try) then they'll presumably keep doing so. And this isn't random newbies, this is GHC's bootlibs! Is it better to have a handy function for it, that comes with documentation telling you not to use it and what to do instead, or to not provide it and risk people using try with a type sig? I don't have strong feelings either way. > In fact, this applies to catchAny too. It should come with a strong > warning, and a suggestion that any unrecognised exceptions should be > re-thrown. Most uses of catchAny are to implement an on-error action > anyway, I think this ought to be provided as a combinator. We have > bracketOnError, but perhaps we should also have > > onException :: IO a -> IO b -> IO a Sounds good to me. Thanks Ian From igloo at earth.li Fri Jul 4 14:53:21 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Jul 4 14:44:20 2008 Subject: Proposal: Extensible exceptions In-Reply-To: <486E3930.5040807@list.mightyreason.com> References: <20080704132924.GA3983@matrix.chaos.earth.li> <486E3930.5040807@list.mightyreason.com> Message-ID: <20080704185321.GB32684@matrix.chaos.earth.li> On Fri, Jul 04, 2008 at 03:52:32PM +0100, Chris Kuklewicz wrote: > Ian Lynagh wrote: > >=== Library function differences > > > >As far as the library functions are concerned, here are the main > >differences: > > > >The old and new types for catch are: > > Old: catch :: IO a -> (Exception -> IO a) -> IO a > > New: catch :: Exception e => IO a -> (e -> IO a) -> IO a > >i.e. catch can now catch any type of exception; we don't have to force > >all the different types of extension into one fixed datatype. > > Is there any sane way to allow extending or building equivalents to these > for MonadIO? I don't think that this change makes it any easier or harder. Thanks Ian From igloo at earth.li Fri Jul 4 15:05:13 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Jul 4 14:56:12 2008 Subject: Proposal: Extensible exceptions In-Reply-To: <2608b8a80807040754s3326fa87nc7700c253ed76425@mail.gmail.com> References: <20080704132924.GA3983@matrix.chaos.earth.li> <2608b8a80807040754s3326fa87nc7700c253ed76425@mail.gmail.com> Message-ID: <20080704190513.GC32684@matrix.chaos.earth.li> On Fri, Jul 04, 2008 at 05:54:11PM +0300, Yitzchak Gale wrote: > Ian Lynagh wrote: > > This is a proposal to replace the current exception mechanism in the > > base library with extensible exceptions... > > How does this affect integration between IO exceptions > and pure exceptions, in particular Control.Monad.Error from mtl? I don't think anything needs to change, but it might be desirable to use a similar sort of extensible-errors. It might even be possible to get rid of the Error class and use the Exception class instead. Thanks Ian From igloo at earth.li Fri Jul 4 15:14:27 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Jul 4 15:05:26 2008 Subject: Proposal: Extensible exceptions In-Reply-To: <1334190008.20080704211747@gmail.com> References: <20080704132924.GA3983@matrix.chaos.earth.li> <1334190008.20080704211747@gmail.com> Message-ID: <20080704191427.GD32684@matrix.chaos.earth.li> On Fri, Jul 04, 2008 at 09:17:47PM +0400, Bulat Ziganshin wrote: > Friday, July 4, 2008, 5:29:24 PM, you wrote: > > > This is a proposal to replace the current exception mechanism in the > > base library with extensible exceptions. > > extensible exceptions, records and syntax are my favorite > missing-in-haskell-garden pets, so my +1000 > > syntax to defining new exceptions is a bit too fat, but it's probably > impossible to use something more direct and consistent like it's done in > OOP languages? If you have alternative suggestions, now is the time to propose them! > is it planned to be included in 6.10? Yes. > how it will work with legacy > code, in particular libraries developed with old base in mind? If you import Control.OldException instead of Control.Exception then it will be identical. But fixing old code to work with the new library is very easy (e.g. changing catch to catchAny if you get an ambiguous type variable), and as Simon pointed out, places were you actually have to make changes could do with being sanity checked anyway. > how > mixed code (throwing/catching exceptions in old and new styles) will > work together? The new catch will catch all the old exceptions. The old catch will catch all the old types of exception thrown by the new throw. Thanks Ian From igloo at earth.li Fri Jul 4 15:18:36 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Jul 4 15:09:36 2008 Subject: Proposal: Extensible exceptions In-Reply-To: References: <20080704132924.GA3983@matrix.chaos.earth.li> Message-ID: <20080704191836.GE32684@matrix.chaos.earth.li> On Sat, Jul 05, 2008 at 03:00:53AM +0900, shelarcy wrote: > On Fri, 04 Jul 2008 22:29:24 +0900, Ian Lynagh wrote: > > > The patches are here: > > http://darcs.haskell.org/ext-excep/ > > I've attached Examples.hs, which gives some examples of using it. > > But It seems that current patches doesn't change GHC.Conc module's > catchSTM type. I think we should change that type, too. I agree; I just hadn't got that far yet. Thanks Ian From allbery at ece.cmu.edu Fri Jul 4 15:22:23 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Jul 4 15:13:23 2008 Subject: Proposal: Extensible exceptions In-Reply-To: <486E2BF6.2060203@gmail.com> References: <20080704132924.GA3983@matrix.chaos.earth.li> <486E2BF6.2060203@gmail.com> Message-ID: On 2008 Jul 4, at 9:56, Simon Marlow wrote: > In fact, this applies to catchAny too. It should come with a strong > warning, and a suggestion that any unrecognised exceptions should be > re-thrown. Most uses of catchAny are to implement Given that it just tries a catch with each exception in the list, why couldn't it automatically re-throw if none matches? -- 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 Fri Jul 4 15:22:08 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Jul 4 15:13:43 2008 Subject: Proposal: Extensible exceptions In-Reply-To: <20080704191427.GD32684@matrix.chaos.earth.li> References: <20080704132924.GA3983@matrix.chaos.earth.li> <1334190008.20080704211747@gmail.com> <20080704191427.GD32684@matrix.chaos.earth.li> Message-ID: <172311660.20080704232208@gmail.com> Hello Ian, Friday, July 4, 2008, 11:14:27 PM, you wrote: > If you import Control.OldException instead of Control.Exception then it > will be identical. > But fixing old code to work with the new library is very easy (e.g. > changing catch to catchAny if you get an ambiguous type variable), and > as Simon pointed out, places were you actually have to make changes > could do with being sanity checked anyway. so, all libs on hackage developed for 6.8 will become obsolete again? :))) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From igloo at earth.li Fri Jul 4 17:10:15 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Jul 4 17:01:14 2008 Subject: Proposal: Extensible exceptions In-Reply-To: References: <20080704132924.GA3983@matrix.chaos.earth.li> <486E2BF6.2060203@gmail.com> Message-ID: <20080704211015.GA2375@matrix.chaos.earth.li> On Fri, Jul 04, 2008 at 03:22:23PM -0400, Brandon S. Allbery KF8NH wrote: > > On 2008 Jul 4, at 9:56, Simon Marlow wrote: > > >In fact, this applies to catchAny too. It should come with a strong > >warning, and a suggestion that any unrecognised exceptions should be > >re-thrown. Most uses of catchAny are to implement > > Given that it just tries a catch with each exception in the list, why > couldn't it automatically re-throw if none matches? I think you're confusing "catchAny" (which catches /any/ sort of exception) with "catches" (which has a list of handlers for different types, and does indeed rethrow exceptions that none of the handlers catch). Thanks Ian From dominic.steinitz at blueyonder.co.uk Sat Jul 5 03:06:35 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Sat Jul 5 02:56:28 2008 Subject: Cabal and c2hs Message-ID: <486F1D7B.5080404@blueyonder.co.uk> Way back in 2005, I was able to build my haskell version of ping with this Setup.hs > import Distribution.Simple > import Distribution.Simple.Utils(rawSystemPath) > > main = > defaultMainWithHooks > defaultUserHooks { > hookedPreProcessors = > [("chs", \_ _ -> myPpC2hs)] > } > > myPpC2hs inFile outFile verbose > = rawSystemPath verbose "c2hs" ["-o", outFile, inFile] rawSystemPath no longer seems to exist (in Distribution.Simple.Utils at any rate). Looking at the latest haddock, there does seem to be > runSimplePreProcessor :: PreProcessor -> FilePath -> FilePath -> Verbosity -> IO () > ppC2hs :: BuildInfo -> LocalBuildInfo -> PreProcessor but I'm struggling to see what I put in BuildInfo and LocalBuildInfo. I presume I put "." as the FilePath? > main = runSimplePreProcessor (ppC2hs undefined undefined) "." "." deafening Is there some way of getting hold of the BuildInfo and LocalBuildInfo to pass into runSimplePreProcessor? Thanks, Dominic. From dominic.steinitz at blueyonder.co.uk Sat Jul 5 03:18:24 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Sat Jul 5 03:08:16 2008 Subject: Cabal and c2hs In-Reply-To: <486F1D7B.5080404@blueyonder.co.uk> References: <486F1D7B.5080404@blueyonder.co.uk> Message-ID: <486F2040.10901@blueyonder.co.uk> Ignore my previous message, it was a lot simpler than I thought it was > import Distribution.Simple > import Distribution.Simple.PreProcess > > main = > defaultMainWithHooks > defaultUserHooks { > hookedPreProcessors = > [("chs", ppC2hs)] > } Dominic. From dominic.steinitz at blueyonder.co.uk Sat Jul 5 03:30:48 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Sat Jul 5 03:20:41 2008 Subject: Cabal and c2hs In-Reply-To: <486F2040.10901@blueyonder.co.uk> References: <486F1D7B.5080404@blueyonder.co.uk> <486F2040.10901@blueyonder.co.uk> Message-ID: <486F2328.4020801@blueyonder.co.uk> Dominic Steinitz wrote: > Ignore my previous message, it was a lot simpler than I thought it was > >> import Distribution.Simple >> import Distribution.Simple.PreProcess >> >> main = >> defaultMainWithHooks >> defaultUserHooks { >> hookedPreProcessors = >> [("chs", ppC2hs)] >> } > > Dominic. > But now I get a build error > dom@lagrange:~/networktools/ping> ./Setup build > Preprocessing executables for Ping-0.0... > dist/build/ping/ping-tmp/IP_ICMP.chs.h:1:21: error: ip_icmp.h: No such file or directory > c2hs: Error during preprocessing custom header file But ip_icmp.h is there! > dom@lagrange:~/networktools/ping> ls -ltr > total 3104 > drwxr-xr-x 7 dom users 4096 2008-07-05 06:50 _darcs > -rw-r--r-- 1 dom users 5487 2008-07-05 06:50 test.hs > -rw-r--r-- 1 dom users 307 2008-07-05 06:50 Setup.hs~ > -rw-r--r-- 1 dom users 250 2008-07-05 06:50 ping.cabal > -rw-r--r-- 1 dom users 591 2008-07-05 06:50 Makefile > -rw-r--r-- 1 dom users 787 2008-07-05 06:50 ip_icmp.h > -rw-r--r-- 1 dom users 212 2008-07-05 06:50 IP_ICMP.chs > -rw-r--r-- 1 dom users 18011 2008-07-05 06:50 gpl.txt > -rw-r--r-- 1 dom users 487 2008-07-05 08:03 Setup.hi > -rw-r--r-- 1 dom users 3684 2008-07-05 08:16 Setup.o > -rwxr-xr-x 1 dom users 3048919 2008-07-05 08:16 Setup > -rw-r--r-- 1 dom users 195 2008-07-05 08:17 Setup.hs > drwxr-xr-x 3 dom users 4096 2008-07-05 08:22 dist > -rw-r--r-- 1 dom users 128 2008-07-05 08:26 IP_ICMP.i How do I tell cabal that ip_icmp.h is in the current directory not buried somewhere? Thanks, Dominic. From gale at sefer.org Sat Jul 5 19:39:52 2008 From: gale at sefer.org (Yitzchak Gale) Date: Sat Jul 5 19:30:48 2008 Subject: Proposal: Extensible exceptions In-Reply-To: <20080704190513.GC32684@matrix.chaos.earth.li> References: <20080704132924.GA3983@matrix.chaos.earth.li> <2608b8a80807040754s3326fa87nc7700c253ed76425@mail.gmail.com> <20080704190513.GC32684@matrix.chaos.earth.li> Message-ID: <2608b8a80807051639y265c69b0k5cdd408b2c723f44@mail.gmail.com> I am now opposed to this proposal as it stands, due to code breakage. However, the proposal is nice, and I think that we could get there via a more friendly path. Discussion and suggestions follow. I wrote: >> How does this affect integration between IO exceptions >> and pure exceptions, in particular Control.Monad.Error from mtl? Ian Lynagh wrote: > I don't think anything needs to change, but it might be desirable to use > a similar sort of extensible-errors. No, the Error class is already extensible. But Exception members are not suitable, since they do not have strMsg and noMsg methods. With the old Exceptions, that was not too bad - you just need to wrap the single Exception data type. This proposed change makes things much messier, and it will break code. > It might even be possible to get rid of the Error class and use the > Exception class instead. I like that idea. In practice, I always find strMsg and noMsg nothing more than an annoyance. What is really needed is a required Show instance, like the Exception class has. And of course, having all Exception instances available as candidates for pure exceptions is nice. But this would be a traumatic change. There would need to be some migration/deprecation path. As Bulat points out, there will be a lot of pain caused even for Exception itself. The fact that it is easy to figure out how to fix code to make it work again (assuming that is true) will not change the fact that many, many programs will no longer compile. Past experience shows that this causes a lot of damage. To get there with less pain, I think we should: o For 6.10, make the new Exceptions available so that everyone can start working on switching, but leave old Exceptions as the default so that existing programs still work. Prominently mark old exceptions as deprecated in all documentation. o In the next version, make the new Exceptions the default. Make sure that programs using new Exceptions for 6.10 will still work (e.g., leave NewException as an alias for Exception, or whatever). In parallel, do something similar for deprecating the mtl Error class and using Exception instead. As a general note - it has been suggested several times that we need a facility like Python's "from future import ...". That would be much better than making up names like "OldException" and "NewException" every time. Though in Python itself, that facility only applies to the core language, not to libraries. When an important library is changed in an incompatible way, they tend to use a new name for the new library and leave the deprecated library around with its old name for years and years. We could also do that here. Another approach would be to build this kind of facility into the package system. Thanks, Yitz From isaacdupree at charter.net Sat Jul 5 20:15:46 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Sat Jul 5 20:06:41 2008 Subject: Proposal: Extensible exceptions In-Reply-To: <20080704185221.GA32684@matrix.chaos.earth.li> References: <20080704132924.GA3983@matrix.chaos.earth.li> <486E2BF6.2060203@gmail.com> <20080704185221.GA32684@matrix.chaos.earth.li> Message-ID: <48700EB2.4020804@charter.net> Ian Lynagh wrote: >> In fact, this applies to catchAny too. It should come with a strong >> warning, and a suggestion that any unrecognised exceptions should be >> re-thrown. Most uses of catchAny are to implement an on-error action >> anyway, I think this ought to be provided as a combinator. We have >> bracketOnError, but perhaps we should also have >> >> onException :: IO a -> IO b -> IO a > > Sounds good to me. similar to `finally` but only for when there are exceptions. finally :: IO a -> IO b -> IO a bracket is to bracketOnError as finally is to... onException? perhaps we can call it finallyOnError so we can understand the parallelism more naturally? :-) (and why is there no "bracket_OnError" :-) But I'd think that sometimes we want to have the exception (e.g. to print it) even if we're `onException`, so we get a slightly more similar signature to catchAny, but safer because it rethrows the exception after the second clause completes: onAny :: IO a -> (forall e . Exception e => e -> IO b) -> IO a Then we encourage this as another alternative to catchAny depending on user's needs. What should we call it -- onAny is bad? Really, `finally` corresponds to `bracket_` -- I'm not too happy with the Control.Exception naming situation right now, maybe I'll try to rethink all the names at once and post a proposal (even if we decide we don't want the API breakage, it'll be useful to make sure we're not leaving out anything else important). By the way, what happens if a `finally` or `onException` clause throws an exception? That exception replaces the the one that we were planning on rethrowing? Does this already induce a risk of accidentally deleting Timeout exceptions (e.g. we replace it with a DiskFull exception accidentally produced by logging a message, that some higher level code catches and then proceeds as normal)? Or do we ignore exceptions in those blocks? (Similar to how exceptions in C++ destructors are just a Bad Idea.) But that risks ignoring a HeapOverflow or asynchronous exception (killThread, timeout...)? no it doesn't, those are just blocked from arriving until the end of the handling-block, and it's just the *synchronous* exceptions that are swallowed? But if the handler does some blocking I/O and thus (unblock), does that mean we risk losing those exceptions again? This confuses me a lot. Are we any better off than imperative languages, e.g. because most of our code isn't in I/O and so it uses proper data structures (Maybe, Either, etc.), rather than exceptions, for legitimate computational possibilities? -Isaac From isaacdupree at charter.net Sat Jul 5 20:17:27 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Sat Jul 5 20:08:22 2008 Subject: Proposal: Extensible exceptions In-Reply-To: <172311660.20080704232208@gmail.com> References: <20080704132924.GA3983@matrix.chaos.earth.li> <1334190008.20080704211747@gmail.com> <20080704191427.GD32684@matrix.chaos.earth.li> <172311660.20080704232208@gmail.com> Message-ID: <48700F17.5020509@charter.net> Bulat Ziganshin wrote: > Hello Ian, > > Friday, July 4, 2008, 11:14:27 PM, you wrote: > >> If you import Control.OldException instead of Control.Exception then it >> will be identical. > >> But fixing old code to work with the new library is very easy (e.g. >> changing catch to catchAny if you get an ambiguous type variable), and >> as Simon pointed out, places were you actually have to make changes >> could do with being sanity checked anyway. > > so, all libs on hackage developed for 6.8 will become obsolete again? :))) > is it equally possible to put a NewException library for hackage ghc<6.9, providing those new function names that we introduce? Would that help reduce gratuituous incompatibility, or would things still break too much, or is it just plain impossible because of module-naming and how base is fixed? :-) -Isaac From dave at zednenem.com Sun Jul 6 03:31:41 2008 From: dave at zednenem.com (David Menendez) Date: Sun Jul 6 03:22:37 2008 Subject: Proposal: Extensible exceptions In-Reply-To: <2608b8a80807051639y265c69b0k5cdd408b2c723f44@mail.gmail.com> References: <20080704132924.GA3983@matrix.chaos.earth.li> <2608b8a80807040754s3326fa87nc7700c253ed76425@mail.gmail.com> <20080704190513.GC32684@matrix.chaos.earth.li> <2608b8a80807051639y265c69b0k5cdd408b2c723f44@mail.gmail.com> Message-ID: <49a77b7a0807060031t49a83516s2d24d7c10a4922c2@mail.gmail.com> On Sat, Jul 5, 2008 at 7:39 PM, Yitzchak Gale wrote: > I wrote: >>> How does this affect integration between IO exceptions >>> and pure exceptions, in particular Control.Monad.Error from mtl? > > Ian Lynagh wrote: [...] >> It might even be possible to get rid of the Error class and use the >> Exception class instead. > > I like that idea. In practice, I always find strMsg and noMsg nothing > more than an annoyance. What is really needed is a required Show > instance, like the Exception class has. And of course, having all > Exception instances available as candidates for pure exceptions > is nice. The Error class is cruft anyway. It only exists so that the Error and ErrorT monads can support "fail" and "mzero". From my standpoint, "fail" shouldn't exist, and the error monads shouldn't conflate mzero and throwErr. But that's another topic. > But this would be a traumatic change. There would need to be some > migration/deprecation path. > > As Bulat points out, there will be a lot of pain caused even > for Exception itself. The fact that it is easy to figure out > how to fix code to make it work again (assuming that is true) > will not change the fact that many, many programs will > no longer compile. Past experience shows that this > causes a lot of damage. > > To get there with less pain, I think we should: > > o For 6.10, make the new Exceptions available so that > everyone can start working on switching, but leave old > Exceptions as the default so that existing programs still > work. Prominently mark old exceptions as deprecated > in all documentation. > > o In the next version, make the new Exceptions the default. > Make sure that programs using new Exceptions for 6.10 > will still work (e.g., leave NewException as an alias for > Exception, or whatever). I have the guts of an extensible exception library modeled on Simon Marlow's paper that can coexist with the current Control.Exception regime. That is, exceptions thrown by "old" code can be caught by "new" code, and vice versa. The trick is adding two secret methods to the Exception class which handle conversion to and from Control.Exception.Exception. > import qualified Control.Exception as Legacy > class (Show e, Typeable e) => Exception e where > toException :: e -> SomeException > fromException :: SomeException -> Maybe e > toLegacyException :: e -> Legacy.Exception > fromLegacyException :: Legacy.Exception -> Maybe e > > toException = SomeException > fromException (SomeException e) = cast e > > toLegacyException = Legacy.DynException . toDyn . toException > fromLegacyException (Legacy.DynException d) > = fromDynamic d >>= fromException > fromLegacyException _ = Nothing Adding new exceptions works exactly as it does in Simon's paper. The wrappers for already existing exceptions silently translate into their current representations. > data DivideByZero = DivideByZero deriving (Show, Typeable) > > instance Exception DivideByZero where > toException = SomeException . toLegacyException > toLegacyException DivideByZero > = Legacy.ArithException Legacy.DivideByZero > > fromException (SomeException e) = cast e >>= fromLegacyException > > fromLegacyException (Legacy.ArithException Legacy.DivideByZero) > = Just DivideByZero > fromLegacyException _ = Nothing This code implements the new exceptions on top of the old exceptions. Eventually, once the new exceptions have gained acceptance, the internals of the library can be changed to implement the old exceptions on top of the new exceptions. I only ever made a partial implementation, but I can post it if anyone is interested. -- Dave Menendez From gale at sefer.org Sun Jul 6 06:07:32 2008 From: gale at sefer.org (Yitzchak Gale) Date: Sun Jul 6 05:58:26 2008 Subject: Proposal: Extensible exceptions In-Reply-To: <49a77b7a0807060031t49a83516s2d24d7c10a4922c2@mail.gmail.com> References: <20080704132924.GA3983@matrix.chaos.earth.li> <2608b8a80807040754s3326fa87nc7700c253ed76425@mail.gmail.com> <20080704190513.GC32684@matrix.chaos.earth.li> <2608b8a80807051639y265c69b0k5cdd408b2c723f44@mail.gmail.com> <49a77b7a0807060031t49a83516s2d24d7c10a4922c2@mail.gmail.com> Message-ID: <2608b8a80807060307l43b1ad4bp1b33da504dc14ed2@mail.gmail.com> Ian Lynagh wrote: >>> It might even be possible to get rid of the Error class and use the >>> Exception class instead. David Menendez wrote: > The Error class is cruft anyway. It only exists so that the Error and > ErrorT monads can support "fail" and "mzero"... > the error monads shouldn't conflate mzero > and throwErr. Agreed. So let's get rid of Error. But please - make it a two step process that gives people time to adapt, not a sudden discontinuity that breaks everything all at once. > I have the guts of an extensible exception library modeled on Simon > Marlow's paper that can coexist with the current Control.Exception > regime. That is, exceptions thrown by "old" code can be caught by > "new" code, and vice versa. Nice. It looks like this addition would allow code that only mentions old exception constructors to keep working, but it would still break code that mentions old exception types. Is this correct? If so, then it would definitely be helpful, but we would still need a two-step deprecation path. Thanks, Yitz From dave at zednenem.com Sun Jul 6 13:34:30 2008 From: dave at zednenem.com (David Menendez) Date: Sun Jul 6 13:25:28 2008 Subject: Proposal: Extensible exceptions In-Reply-To: <2608b8a80807060307l43b1ad4bp1b33da504dc14ed2@mail.gmail.com> References: <20080704132924.GA3983@matrix.chaos.earth.li> <2608b8a80807040754s3326fa87nc7700c253ed76425@mail.gmail.com> <20080704190513.GC32684@matrix.chaos.earth.li> <2608b8a80807051639y265c69b0k5cdd408b2c723f44@mail.gmail.com> <49a77b7a0807060031t49a83516s2d24d7c10a4922c2@mail.gmail.com> <2608b8a80807060307l43b1ad4bp1b33da504dc14ed2@mail.gmail.com> Message-ID: <49a77b7a0807061034n71304390obc020b446f1fc2c4@mail.gmail.com> On Sun, Jul 6, 2008 at 6:07 AM, Yitzchak Gale wrote: > David Menendez wrote: >> I have the guts of an extensible exception library modeled on Simon >> Marlow's paper that can coexist with the current Control.Exception >> regime. That is, exceptions thrown by "old" code can be caught by >> "new" code, and vice versa. > > Nice. It looks like this addition would allow code that only mentions > old exception constructors to keep working, but it would still > break code that mentions old exception types. Is this correct? My implementation doesn't touch Control.Exception at all, so existing code would still work unmodified. The new throw and catch are in a different module, and everything else is exactly the way it was before. The clever part is that the new code can throw a new version of a pre-existing exception, e.g. DivByZero, and existing code which is looking for (ArithException DivByZero) will still catch it, and vice versa, without changing or even recompiling the old code. I implemented the new exceptions on top of the current ones because I didn't want to mess around with GHC's internals. It's possible to implement extensible exceptions in GHC while still fully supporting the existing Control.Exception interface. The idea is to re-implement Old.throw and Old.catch in terms of New.throw and New.catch. (In contrast, my code implements New.throw and New.catch in terms of Old.throw and Old.catch.) The hard part is coming up with a new module name, since Control.Exception is taken. -- Dave Menendez From lemming at henning-thielemann.de Sun Jul 6 16:13:56 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun Jul 6 16:04:51 2008 Subject: Proposal: Extensible exceptions In-Reply-To: <1334190008.20080704211747@gmail.com> References: <20080704132924.GA3983@matrix.chaos.earth.li> <1334190008.20080704211747@gmail.com> Message-ID: On Fri, 4 Jul 2008, Bulat Ziganshin wrote: > Hello Ian, > > Friday, July 4, 2008, 5:29:24 PM, you wrote: > >> This is a proposal to replace the current exception mechanism in the >> base library with extensible exceptions. > > extensible exceptions, records and syntax are my favorite > missing-in-haskell-garden pets, so my +1000 In Modula-3 you have to add the exceptions that can be raised to a PROCEDURE header. Java has adopted this mechanism. http://www.cs.sfu.ca/~cameron/Teaching/383/Exceptions.html I think that's a very clean and safe approach and it can be easily adopted in Haskell, although not as a drop-in replacement. If I call an IO action I want to know precisely what exceptions or possible extensions I have to expect. We can nicely formulate this in Haskell. Say, pure IO never throws exceptions and exceptions are implemented as exceptional return values, like readFile :: IO (Either IOError String) Instead of Either we should use a specific datatype, say data ExceptionalResult e a = Success a | Exception e and (IO (ExceptionalResult IOError String)) could be wrapped in a monad transformer like ErrorT (ErrorT is not the right name, because it is not intended to handle 'error's): ExceptionalAction IOError IO String Now 'catch' gets the signature: catch :: ExceptionalAction e0 m a -> (e0 -> ExceptionalAction e1 m a) -> ExceptionalAction e1 m a E.g. a routine that wants to call system routines with IOError exceptions can wrap IOError in a custom datatype like data MyException = TooLazyToday | IOError IOError and a catch call would look like catch m (\e -> case e of TooLazyToday -> return "bla" IOError err -> throw err) From lemming at henning-thielemann.de Sun Jul 6 16:31:05 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun Jul 6 16:22:00 2008 Subject: Proposal: Extensible exceptions In-Reply-To: <49a77b7a0807060031t49a83516s2d24d7c10a4922c2@mail.gmail.com> References: <20080704132924.GA3983@matrix.chaos.earth.li> <2608b8a80807040754s3326fa87nc7700c253ed76425@mail.gmail.com> <20080704190513.GC32684@matrix.chaos.earth.li> <2608b8a80807051639y265c69b0k5cdd408b2c723f44@mail.gmail.com> <49a77b7a0807060031t49a83516s2d24d7c10a4922c2@mail.gmail.com> Message-ID: On Sun, 6 Jul 2008, David Menendez wrote: >> data DivideByZero = DivideByZero deriving (Show, Typeable) Maybe I annoy you with my distinction of errors and exceptions, but I consider DivideByZero a bad example for an exception, because it is more an error (I see it is used in the extensible exception paper anyway). A division by zero is not a problem that comes from the outside world like 'file does not exist'. In contrast to that, it's absolutely predictable: It occurs whenever you divide by zero. I'd thus call it a programming error. From dave at zednenem.com Sun Jul 6 17:31:34 2008 From: dave at zednenem.com (David Menendez) Date: Sun Jul 6 17:22:27 2008 Subject: Proposal: Extensible exceptions In-Reply-To: References: <20080704132924.GA3983@matrix.chaos.earth.li> <2608b8a80807040754s3326fa87nc7700c253ed76425@mail.gmail.com> <20080704190513.GC32684@matrix.chaos.earth.li> <2608b8a80807051639y265c69b0k5cdd408b2c723f44@mail.gmail.com> <49a77b7a0807060031t49a83516s2d24d7c10a4922c2@mail.gmail.com> Message-ID: <49a77b7a0807061431x482041b1v1a1851b9005a3d84@mail.gmail.com> On Sun, Jul 6, 2008 at 4:31 PM, Henning Thielemann wrote: > > On Sun, 6 Jul 2008, David Menendez wrote: > >>> data DivideByZero = DivideByZero deriving (Show, Typeable) > > Maybe I annoy you with my distinction of errors and exceptions, but I > consider DivideByZero a bad example for an exception, because it is more an > error (I see it is used in the extensible exception paper anyway). It's also in the current Control.Exception library. While dividing by zero or accessing an array out of bounds isn't the same as a file not existing, I'm not sure we need different mechanisms for dealing with them. If your code divides by zero, you still want any "finally" or "bracket" clauses to get called before the program terminates. -- Dave Menendez From isaacdupree at charter.net Sun Jul 6 17:32:02 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Sun Jul 6 17:22:53 2008 Subject: Proposal: Extensible exceptions In-Reply-To: References: <20080704132924.GA3983@matrix.chaos.earth.li> <2608b8a80807040754s3326fa87nc7700c253ed76425@mail.gmail.com> <20080704190513.GC32684@matrix.chaos.earth.li> <2608b8a80807051639y265c69b0k5cdd408b2c723f44@mail.gmail.com> <49a77b7a0807060031t49a83516s2d24d7c10a4922c2@mail.gmail.com> Message-ID: <487139D2.6080400@charter.net> Henning Thielemann wrote: > > On Sun, 6 Jul 2008, David Menendez wrote: > >>> data DivideByZero = DivideByZero deriving (Show, Typeable) > > Maybe I annoy you with my distinction of errors and exceptions, but I > consider DivideByZero a bad example for an exception, because it is more > an error (I see it is used in the extensible exception paper anyway). A > division by zero is not a problem that comes from the outside world like > 'file does not exist'. In contrast to that, it's absolutely predictable: > It occurs whenever you divide by zero. I'd thus call it a programming > error. Indeed, we should give some thought to which exceptions are programming errors (divide by zero, assert-failure, error, but not Neil Mitchell's abort...) and put them in a category. We should give some thought to the hierarchy of exceptions we're establishing! I have some trouble seeing from the patches what the hierarchy of exceptions will be; Ian (or someone), could you describe what the current proposal is for that hierarchy? (if it exists yet) -Isaac From lemming at henning-thielemann.de Sun Jul 6 18:05:40 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun Jul 6 17:56:32 2008 Subject: Proposal: Extensible exceptions In-Reply-To: <49a77b7a0807061431x482041b1v1a1851b9005a3d84@mail.gmail.com> References: <20080704132924.GA3983@matrix.chaos.earth.li> <2608b8a80807040754s3326fa87nc7700c253ed76425@mail.gmail.com> <20080704190513.GC32684@matrix.chaos.earth.li> <2608b8a80807051639y265c69b0k5cdd408b2c723f44@mail.gmail.com> <49a77b7a0807060031t49a83516s2d24d7c10a4922c2@mail.gmail.com> <49a77b7a0807061431x482041b1v1a1851b9005a3d84@mail.gmail.com> Message-ID: On Sun, 6 Jul 2008, David Menendez wrote: > On Sun, Jul 6, 2008 at 4:31 PM, Henning Thielemann > wrote: >> >> On Sun, 6 Jul 2008, David Menendez wrote: >> >>>> data DivideByZero = DivideByZero deriving (Show, Typeable) >> >> Maybe I annoy you with my distinction of errors and exceptions, but I >> consider DivideByZero a bad example for an exception, because it is more an >> error (I see it is used in the extensible exception paper anyway). > > It's also in the current Control.Exception library. There are many things wrong about Errors and Exceptions in the current Haskell library: http://www.haskell.org/haskellwiki/Exception http://www.haskell.org/haskellwiki/Error > While dividing by zero or accessing an array out of bounds isn't the > same as a file not existing, I'm not sure we need different mechanisms > for dealing with them. Yes! Because there is no need to recover from an error. Instead an error must be fixed by the programmer. The program cannot do this by itself. I consider recovering from an error like in a web-server a hack, like catching and recovering from an 'error' in IO is a hack, just like unsafePerformIO. I accept that we need a hack in order to tell the user "please send a bug-report to XYZ", but a hack should be called a hack, not "proper exception handling". > If your code divides by zero, you still want any "finally" or "bracket" > clauses to get called before the program terminates. A program which divides by zero is broken and must be fixed. A program which divides by zero but cleans up a bit, is still broken and must be fixed. Cleaning up may make things better, but may also make things worse! Handling errors is the task of Debugging, not that of Exception Handling. I suggest special variants of 'finally' and 'bracket' for bracketing bugs should be located below "Debug" in the module hierarchy. From isaacdupree at charter.net Sun Jul 6 18:32:57 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Sun Jul 6 18:23:56 2008 Subject: Proposal: Extensible exceptions In-Reply-To: References: <20080704132924.GA3983@matrix.chaos.earth.li> <2608b8a80807040754s3326fa87nc7700c253ed76425@mail.gmail.com> <20080704190513.GC32684@matrix.chaos.earth.li> <2608b8a80807051639y265c69b0k5cdd408b2c723f44@mail.gmail.com> <49a77b7a0807060031t49a83516s2d24d7c10a4922c2@mail.gmail.com> <49a77b7a0807061431x482041b1v1a1851b9005a3d84@mail.gmail.com> Message-ID: <48714819.5090302@charter.net> Henning Thielemann wrote: >> If your code divides by zero, you still want any "finally" or >> "bracket" clauses to get called before the program terminates. > > A program which divides by zero is broken and must be fixed. A program > which divides by zero but cleans up a bit, is still broken and must be > fixed. Cleaning up may make things better, but may also make things > worse! it can make things worse? (When cleanup is somehow significantly dependent on the buggy part of the code that led to the error? How often does that happen??) I appreciate how bugs in Haskell are much better-behaved than many languages. For finally-clauses, they should be called equally whether there is a legitimate IO exception (if you believe in such a thing; they're even in Haskell98 in a form), or a buggy-program exception, and there is no good reason to fail to call 'hClose' just because some pure code in some part of the program divided by zero. Especially because of Haskell's laziness, that division by zero might have been lexically called somewhere before opening the handle, but be evaluated after it's been opened and before it's been closed! This way, if my IO uses 'bracket' when it should, a bug in one part of the code is less likely to cause obscure bugs in entirely unrelated IO parts of the code. Exceptions are designed to be ubiquitous and always-possible... especially when you consider asynchronous exceptions. In fact it's possible to use these exception capabilities to isolate different parts of the program from each other's bugs so the whole thing doesn't crash: although that's when it becomes much closer to your assessment of "a hack". That "hack" still can be quite useful, of course, if you agree with the Awkward Squad paper. It depends whether modularity of bugs is part of your worldview?-- I'm glad Linux (and all other modern OS) isolates different processes' address spaces using MMU! -Isaac From dave at zednenem.com Sun Jul 6 19:24:19 2008 From: dave at zednenem.com (David Menendez) Date: Sun Jul 6 19:15:12 2008 Subject: Proposal: Extensible exceptions In-Reply-To: References: <20080704132924.GA3983@matrix.chaos.earth.li> <2608b8a80807040754s3326fa87nc7700c253ed76425@mail.gmail.com> <20080704190513.GC32684@matrix.chaos.earth.li> <2608b8a80807051639y265c69b0k5cdd408b2c723f44@mail.gmail.com> <49a77b7a0807060031t49a83516s2d24d7c10a4922c2@mail.gmail.com> <49a77b7a0807061431x482041b1v1a1851b9005a3d84@mail.gmail.com> Message-ID: <49a77b7a0807061624j24594043w3e698842e6e673dc@mail.gmail.com> On Sun, Jul 6, 2008 at 6:05 PM, Henning Thielemann wrote: > >> While dividing by zero or accessing an array out of bounds isn't the >> same as a file not existing, I'm not sure we need different mechanisms >> for dealing with them. > > Yes! Because there is no need to recover from an error. Instead an error > must be fixed by the programmer. The program cannot do this by itself. I > consider recovering from an error like in a web-server a hack, like catching > and recovering from an 'error' in IO is a hack, just like unsafePerformIO. I > accept that we need a hack in order to tell the user "please send a > bug-report to XYZ", but a hack should be called a hack, not "proper > exception handling". I don't recall calling anything "proper exception handling". I said that it's reasonable to report certain programming errors through the exception handling mechanism because it allows a running program to clean up before it terminates. >> If your code divides by zero, you still want any "finally" or "bracket" >> clauses to get called before the program terminates. > > A program which divides by zero is broken and must be fixed. A program which > divides by zero but cleans up a bit, is still broken and must be fixed. > Cleaning up may make things better, but may also make things worse! Handling > errors is the task of Debugging, not that of Exception Handling. I suggest > special variants of 'finally' and 'bracket' for bracketing bugs should be > located below "Debug" in the module hierarchy. Yes, a program that divides by zero should be fixed. If a program has, say, locked a file and then encounters an error, are you suggesting that the program should crash without unlocking the file? The fact that the program shouldn't have encountered an error is irrelevant. -- Dave Menendez From lemming at henning-thielemann.de Mon Jul 7 05:47:35 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Jul 7 05:38:51 2008 Subject: Proposal: Extensible exceptions In-Reply-To: <49a77b7a0807061624j24594043w3e698842e6e673dc@mail.gmail.com> References: <20080704132924.GA3983@matrix.chaos.earth.li> <2608b8a80807040754s3326fa87nc7700c253ed76425@mail.gmail.com> <20080704190513.GC32684@matrix.chaos.earth.li> <2608b8a80807051639y265c69b0k5cdd408b2c723f44@mail.gmail.com> <49a77b7a0807060031t49a83516s2d24d7c10a4922c2@mail.gmail.com> <49a77b7a0807061431x482041b1v1a1851b9005a3d84@mail.gmail.com> <49a77b7a0807061624j24594043w3e698842e6e673dc@mail.gmail.com> Message-ID: On Sun, 6 Jul 2008, David Menendez wrote: > I don't recall calling anything "proper exception handling". I said > that it's reasonable to report certain programming errors through the > exception handling mechanism because it allows a running program to > clean up before it terminates. You can try to report programming errors to the user - but that's debugging. Where is the need to mix that with regular exception handling? >>> If your code divides by zero, you still want any "finally" or "bracket" >>> clauses to get called before the program terminates. >> >> A program which divides by zero is broken and must be fixed. A program which >> divides by zero but cleans up a bit, is still broken and must be fixed. >> Cleaning up may make things better, but may also make things worse! Handling >> errors is the task of Debugging, not that of Exception Handling. I suggest >> special variants of 'finally' and 'bracket' for bracketing bugs should be >> located below "Debug" in the module hierarchy. > > Yes, a program that divides by zero should be fixed. If a program has, > say, locked a file and then encounters an error, are you suggesting > that the program should crash without unlocking the file? If your program is buggy, then it may well be that the file to unlock is already unlocked and deleted. By trying to recover from an error a division by zero can cause even more severe damages. It is not possible to handle errors in a way like exceptions, because exceptions are (rare but) expected situations, that can well be handled. In contrast to that you do not know the concrete errors in your program, otherwise you would have fixed them already. From lemming at henning-thielemann.de Mon Jul 7 06:20:06 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Jul 7 06:10:58 2008 Subject: Proposal: Extensible exceptions In-Reply-To: <48714819.5090302@charter.net> References: <20080704132924.GA3983@matrix.chaos.earth.li> <2608b8a80807040754s3326fa87nc7700c253ed76425@mail.gmail.com> <20080704190513.GC32684@matrix.chaos.earth.li> <2608b8a80807051639y265c69b0k5cdd408b2c723f44@mail.gmail.com> <49a77b7a0807060031t49a83516s2d24d7c10a4922c2@mail.gmail.com> <49a77b7a0807061431x482041b1v1a1851b9005a3d84@mail.gmail.com> <48714819.5090302@charter.net> Message-ID: On Sun, 6 Jul 2008, Isaac Dupree wrote: > Henning Thielemann wrote: >>> If your code divides by zero, you still want any "finally" or "bracket" >>> clauses to get called before the program terminates. >> >> A program which