From marlowsd at gmail.com Wed Jul 1 05:02:57 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jul 1 04:45:33 2009 Subject: base library and GHC 6.12 In-Reply-To: <20090630093835.5ef53c71.Malcolm.Wallace@cs.york.ac.uk> References: <20090625150214.GA28561@matrix.chaos.earth.li> <4A4570B5.70104@henning-thielemann.de> <4A48B1FD.8090809@gmail.com> <4A48D898.6080203@isaac.cedarswampstudios.org> <4A49C149.9070700@gmail.com> <20090630093835.5ef53c71.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <4A4B2641.6040005@gmail.com> On 30/06/2009 09:38, Malcolm Wallace wrote: > Simon Marlow wrote: > >>> 6.12 ... Are there any >>> particular release-cycle deadlines for that >> We'd need the changes in GHC *and* Haddock in time for GHC 6.12.1, >> since the two are shipped together, and we need Haddock working to >> build the 6.12.1 library docs. I think it's doable, though. > > GHC usually tries to ship a major new release every year, around ICFP > time. The conference is rather earlier this yes than most years, so is > the ghc release schedule for 6.12.1 time-advanced as well? We haven't fixed a date, but I imagine we'll try to release in September, October at the latest. Cheers, Simon From ross at soi.city.ac.uk Wed Jul 1 07:15:21 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Jul 1 06:57:58 2009 Subject: proposal #3335: make some Applicative functions into methods, and split off Data.Functor In-Reply-To: <20090701012457.GJ22067@sliver.repetae.net> References: <20090629124545.GA6378@soi.city.ac.uk> <7fb8f82f0906300845o5bc6814aie14d60dadd4d3e7a@mail.gmail.com> <20090630155813.GA8166@soi.city.ac.uk> <20090701012457.GJ22067@sliver.repetae.net> Message-ID: <20090701111521.GA5992@soi.city.ac.uk> On Tue, Jun 30, 2009 at 06:24:57PM -0700, John Meacham wrote: > On Tue, Jun 30, 2009 at 04:58:13PM +0100, Ross Paterson wrote: > > Ah, but that's changing the meaning, which isn't what these are supposed > > to be for. > > I don't see why not. As long as your versions follow whatever rules are > specified for the class. The rules specified in this case are that the specialized version defines the same function as the default definition. > frisby also cannot use Applicative as is > because these methods arn't able to be overridden and the default > implementations lead to pessimal (to the point of unusabality, or even > non-termination) performance. However frisby can provide perfectly valid > implementations of them that follow the Applicative laws and have no > such issues. Something doesn't add up here: things that don't terminate are not equal to things that do. > Actually, 'Alternative' doesn't have any rules as to its meaning, which > is probably why the broken 'many' and 'some' ended up there in the first > place. Personally, I'd prefer just to drop 'many' and 'some' (and > perhaps 'Alternative' itself) completely since it isn't clear meaningful > definitions exist for what we might consider members of 'Alternative'. It's true that Alternative is loosely specified, requiring only a monoid, but it's still very useful (like MonadPlus). In my opinion, the compelling application is "Parsing Permutation Phrases", by Arthur Baars, Andres Loeh and S. Doaitse Swierstra, Haskell Workshop 2001 (see the action-permutations package). It does seem that your application doesn't fit the class, but it's not clear how dropping it would help. From ross at soi.city.ac.uk Wed Jul 1 07:23:40 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Jul 1 07:06:14 2009 Subject: proposal #3335: make some Applicative functions into methods, and split off Data.Functor In-Reply-To: References: <20090629124545.GA6378@soi.city.ac.uk> Message-ID: <20090701112340.GB5992@soi.city.ac.uk> On Tue, Jun 30, 2009 at 01:37:05PM +0200, Henning Thielemann wrote: > On Mon, 29 Jun 2009, Ross Paterson wrote: >> The proposal is that the following functions >> >> (<$) :: Functor f => a -> f b -> f a >> (*>) :: Applicative f => f a -> f b -> f b >> (<*) :: Applicative f => f a -> f b -> f a >> some :: Alternative f => f a -> f [a] >> many :: Alternative f => f a -> f [a] >> >> are moved into the corresponding classes, with the existing implementations >> as default definitions. This gives people creating instances the option of >> defining specialized implementations of these functions, though they should >> be equivalent to the default definitions. > > This sounds like a rather ad-hoc extension of the already complicated > hierarchy of those category classes. Are there particular examples where > the specialisation is needed and where it cannot be done by optimizer > rules? In case the specialised functions differ semantically from the > default implementations - are there generic algorithms that rely on these > semantic exceptions? Otherwise specialised functons can well be > implemented as plain functions and don't need to be type class methods. I think this is a fair point: each proposed method should be justified by a concrete example (i.e. code) of an equivalent definition that achieves a significant performance improvement that one could not reasonably expect from an optimizer. I've given one for (<$). From duncan.coutts at worc.ox.ac.uk Wed Jul 1 08:07:00 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jul 1 07:50:28 2009 Subject: exposing hidden packages with runghc In-Reply-To: References: Message-ID: <1246450020.7418.1.camel@localhost> On Tue, 2009-06-30 at 15:44 +0100, Iain Barnett wrote: > I'm trying to install HTTP-3000.0.0 (because I don't have > cabal-install, and it's a dependency for cabal-install 0.4.9) I highly recommend against using such old versions. cabal-install only really became usable around version 0.6. The latest is 0.6.2 and that's the one you should try. > This is on a Debian 5.1 machine with GHC 6.8.2 and 6.8.3 on it. The latest version of cabal-install should work fine there. Duncan From ekmett at gmail.com Wed Jul 1 10:59:57 2009 From: ekmett at gmail.com (Edward Kmett) Date: Wed Jul 1 10:42:30 2009 Subject: Proposal #3339: Add (+>) as a synonym for mappend In-Reply-To: References: Message-ID: <7fb8f82f0907010759v56d5456cy679333d414aa3888@mail.gmail.com> Bikeshedding: Would it be better to put the definition for +> (or better yet <>) in the dictionary for Monoid with a circular definition for mappend? That way new code defining Monoid instances can avoid ever having to even mention mappend. I'm ok with it either way. I admit adding it to the dictionary might add dictionary passing overhead and risk inconsistent definitions of <> and mappend. -Edward Kmett On Tue, Jun 30, 2009 at 5:37 PM, Bryan O'Sullivan wrote: > Ticket: http://hackage.haskell.org/trac/ghc/ticket/3339 > > From the ticket: > > This proposal was, I think, originally suggested by Jules Bean. The idea is > to add two functions to the Data.Monoid module, (+>) and (<+), > corresponding to different uses of mappend. These should not be methods of > the Monoid typeclass, but top-level functions. > > I hope (but slightly doubt) that the visual nature of the two operators > might help to counter the thought that monoids are just for gluing things > together. > > (+>) :: (Monoid a) => a -> a -> a > a +> b = a `mappend` b > > (<+) :: (Monoid a) => a -> a -> a > a <+ b = b `mappend` a > > infixl 4 +> > infixl 4 <+ > > Proposed deadline: two weeks. > > If this looks reasonable, I'll attach darcs patches. > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090701/82512859/attachment.html From gwern0 at gmail.com Wed Jul 1 16:45:45 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Wed Jul 1 16:28:18 2009 Subject: Adding an ignore function to Control.Monad In-Reply-To: References: Message-ID: Alright, I see that there haven't been any real complaints about adding Control.Monad.ignore since I first posted on 10 June. (Although there was a lot of related-but-off-topic discussion.) Since then, Don Stewart has pointed out http://hackage.haskell.org/trac/ghc/ticket/3292 that there is a very similar function specified in the FFI standard http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi/ffise5.html#x8-350005.10 - 'void :: IO a -> IO ()'. I don't favor 'ignore' over 'void' to an extent significant enough to make that an issue. But it's no longer clear what to do. Do we move void with its current type to Control.Monad and have Foreign.Marshal.Error re-export it? Do we define void with the generalized Functor sig, and have F.M.E re-export with a restricted type sig? Do we simply use my ignore patch and define F.M.E.void = ignore (with the restricted type sig)? The specifics of what to do are unclear enough that I don't think there's consensus for what to do with void, even if we clearly want some sort of void/ignore in Control.Monad. -- gwern From ml at isaac.cedarswampstudios.org Wed Jul 1 23:11:46 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Wed Jul 1 22:54:30 2009 Subject: Adding an ignore function to Control.Monad In-Reply-To: References: Message-ID: <4A4C2572.60006@isaac.cedarswampstudios.org> Gwern Branwen wrote: > Since then, Don Stewart has pointed out > http://hackage.haskell.org/trac/ghc/ticket/3292 that there is a very > similar function specified in the FFI standard > http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi/ffise5.html#x8-350005.10 > - 'void :: IO a -> IO ()'. Are we willing to change (generalize) the type of Foreign.Marshal.Error.void? If so, we could export (void :: Functor m => m a -> m ()) from both Control.Monad and F.M.E (if we wanted to). If we're not willing, then I think it would be a bit more convenient to name them different things (so that if you import both modules you don't get a name-conflict for using 'void'). I vote to just name it Control.Monad.ignore . Many people independently invented the name "ignore" in their own projects. Also I suspect the name "void" in FFI has some etymology in C's equivalent, casting expressions to void (eg: (void)printf(something); ) which I doubt most haskell coders care about most of the time? -Isaac From dave at zednenem.com Thu Jul 2 01:16:23 2009 From: dave at zednenem.com (David Menendez) Date: Thu Jul 2 00:58:54 2009 Subject: Adding an ignore function to Control.Monad In-Reply-To: References: Message-ID: <49a77b7a0907012216q1c07874ct6b5639063471c62@mail.gmail.com> On Wed, Jul 1, 2009 at 4:45 PM, Gwern Branwen wrote: > Alright, I see that there haven't been any real complaints about > adding Control.Monad.ignore since I first posted on 10 June. (Although > there was a lot of related-but-off-topic discussion.) I'll complain. I'm still not convinced that we need a name for (>> return ()). -- Dave Menendez From ndmitchell at gmail.com Thu Jul 2 02:26:45 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Jul 2 02:09:19 2009 Subject: Adding an ignore function to Control.Monad In-Reply-To: <4A4C2572.60006@isaac.cedarswampstudios.org> References: <4A4C2572.60006@isaac.cedarswampstudios.org> Message-ID: <404396ef0907012326j6ca93absa27d01bcf04eafe1@mail.gmail.com> void is the wrong name, wrong type, wrong purpose and wrong module. We could fix all those things, but I think we should just add ignore as previously agreed (+1 for that) Thanks, Neil On Thu, Jul 2, 2009 at 4:11 AM, Isaac Dupree wrote: > Gwern Branwen wrote: >> >> Since then, Don Stewart has pointed out >> http://hackage.haskell.org/trac/ghc/ticket/3292 that there is a very >> similar function specified in the FFI standard >> http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi/ffise5.html#x8-350005.10 >> - 'void ? ? :: IO a -> IO ()'. > > Are we willing to change (generalize) the type of > Foreign.Marshal.Error.void? ?If so, we could export (void :: Functor m => m > a -> m ()) from both Control.Monad and F.M.E (if we wanted to). ?If we're > not willing, then I think it would be a bit more convenient to name them > different things (so that if you import both modules you don't get a > name-conflict for using 'void'). > > I vote to just name it Control.Monad.ignore . ?Many people independently > invented the name "ignore" in their own projects. ?Also I suspect the name > "void" in FFI has some etymology in C's equivalent, casting expressions to > void (eg: (void)printf(something); ) which I doubt most haskell coders care > about most of the time? > > -Isaac > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From ekmett at gmail.com Thu Jul 2 04:00:15 2009 From: ekmett at gmail.com (Edward Kmett) Date: Thu Jul 2 03:42:45 2009 Subject: Adding an ignore function to Control.Monad In-Reply-To: <404396ef0907012326j6ca93absa27d01bcf04eafe1@mail.gmail.com> References: <4A4C2572.60006@isaac.cedarswampstudios.org> <404396ef0907012326j6ca93absa27d01bcf04eafe1@mail.gmail.com> Message-ID: <7fb8f82f0907020100n4a8bc570q60e9550ec57aef0a@mail.gmail.com> I agree with Neil on all those points. F.M.E.void has too many things to fix to bring it inline with ignore in one go and a worse name. +1 on adding ignore though. -Edward Kmett On Thu, Jul 2, 2009 at 2:26 AM, Neil Mitchell wrote: > void is the wrong name, wrong type, wrong purpose and wrong module. We > could fix all those things, but I think we should just add ignore as > previously agreed (+1 for that) > > Thanks, Neil > > On Thu, Jul 2, 2009 at 4:11 AM, Isaac > Dupree wrote: > > Gwern Branwen wrote: > >> > >> Since then, Don Stewart has pointed out > >> http://hackage.haskell.org/trac/ghc/ticket/3292 that there is a very > >> similar function specified in the FFI standard > >> > http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi/ffise5.html#x8-350005.10 > >> - 'void :: IO a -> IO ()'. > > > > Are we willing to change (generalize) the type of > > Foreign.Marshal.Error.void? If so, we could export (void :: Functor m => > m > > a -> m ()) from both Control.Monad and F.M.E (if we wanted to). If we're > > not willing, then I think it would be a bit more convenient to name them > > different things (so that if you import both modules you don't get a > > name-conflict for using 'void'). > > > > I vote to just name it Control.Monad.ignore . Many people independently > > invented the name "ignore" in their own projects. Also I suspect the > name > > "void" in FFI has some etymology in C's equivalent, casting expressions > to > > void (eg: (void)printf(something); ) which I doubt most haskell coders > care > > about most of the time? > > > > -Isaac > > _______________________________________________ > > Libraries mailing list > > Libraries@haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090702/e49a3b05/attachment.html From martijn at van.steenbergen.nl Thu Jul 2 06:42:33 2009 From: martijn at van.steenbergen.nl (Martijn van Steenbergen) Date: Thu Jul 2 06:25:04 2009 Subject: Adding an ignore function to Control.Monad In-Reply-To: <49a77b7a0907012216q1c07874ct6b5639063471c62@mail.gmail.com> References: <49a77b7a0907012216q1c07874ct6b5639063471c62@mail.gmail.com> Message-ID: <4A4C8F19.7040405@van.steenbergen.nl> David Menendez wrote: > On Wed, Jul 1, 2009 at 4:45 PM, Gwern Branwen wrote: >> Alright, I see that there haven't been any real complaints about >> adding Control.Monad.ignore since I first posted on 10 June. (Although >> there was a lot of related-but-off-topic discussion.) > > I'll complain. I'm still not convinced that we need a name for (>> return ()). I think adding ignore is a good idea. I have several examples where I call a function expecting an M () but the last statement in my argument do-block has type M A. For that alone already I think ignore is valuable idiom. Martijn. From iainspeed at gmail.com Thu Jul 2 09:44:36 2009 From: iainspeed at gmail.com (Iain Barnett) Date: Thu Jul 2 09:27:09 2009 Subject: exposing hidden packages with runghc In-Reply-To: <1246450020.7418.1.camel@localhost> References: <1246450020.7418.1.camel@localhost> Message-ID: 2009/7/1 Gwern Branwen > Cabal by default hides everything listed in ghc-pkg, only > making available the ones listed in the .cabal file. So a solution to > your problem would be something like editing http.cabal and adding > array to the build-depends field. > > -- > gwern that threw up syntax errors, obviously I was screwing up something I found out that cabal installs locally by default but runghc installs globally by default, so I went back and reinstalled everything with the --user flag and this fixed the problem, regarding installing packages and hiding, that is. 2009/7/1 Daniel Fischer > > But why are you trying to build such an outdated cabal-install? > > Because I've had a lot of trouble installing the latest versions, and found Dependency Hell to be just as bad as Version Hell was before .Net on Windows, so I've been trying to work up the versions from the beginning, on the logic that they should have less dependencies as there weren't as many things to depend on. Then I have some sort of foundation to use. 2009/7/1 Duncan Coutts > > > > This is on a Debian 5.1 machine with GHC 6.8.2 and 6.8.3 on it. > > The latest version of cabal-install should work fine there. > > Duncan Unless you've actually tried installing it on there lately, then I'd have to disagree. I've now got GHC 6.10.3 running and Cabal 1.6.0.3, and all the packages needed for cabal-install, and still, it won't go on using runghc or ghc to build it. I will keep on trying, and when it's done I'll try and work out how to package it for Debian so it just works, and helps keep the suicide/murder rate down. Iain -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090702/c48e8301/attachment-0001.html From dons at galois.com Thu Jul 2 13:22:17 2009 From: dons at galois.com (Don Stewart) Date: Thu Jul 2 13:06:46 2009 Subject: Adding an ignore function to Control.Monad In-Reply-To: <7fb8f82f0907020100n4a8bc570q60e9550ec57aef0a@mail.gmail.com> References: <4A4C2572.60006@isaac.cedarswampstudios.org> <404396ef0907012326j6ca93absa27d01bcf04eafe1@mail.gmail.com> <7fb8f82f0907020100n4a8bc570q60e9550ec57aef0a@mail.gmail.com> Message-ID: <20090702172217.GE27889@whirlpool.galois.com> I for one don't like 'ignore' -- it implies to me somehow that the argument itself is ignored, rather than the result after evaluation. Also, 'void' already exists, and is part of a decade-old FFI standard. -- Don ekmett: > I agree with Neil on all those points. F.M.E.void has too many things to fix to > bring it inline with ignore in one go and a worse name.? > > +1 on adding ignore though. > > -Edward Kmett > > On Thu, Jul 2, 2009 at 2:26 AM, Neil Mitchell wrote: > > void is the wrong name, wrong type, wrong purpose and wrong module. We > could fix all those things, but I think we should just add ignore as > previously agreed (+1 for that) > > Thanks, Neil > > On Thu, Jul 2, 2009 at 4:11 AM, Isaac > Dupree wrote: > > Gwern Branwen wrote: > >> > >> Since then, Don Stewart has pointed out > >> http://hackage.haskell.org/trac/ghc/ticket/3292 that there is a very > >> similar function specified in the FFI standard > >> http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi/ffise5.html# > x8-350005.10 > >> - 'void ? ? :: IO a -> IO ()'. > > > > Are we willing to change (generalize) the type of > > Foreign.Marshal.Error.void? ?If so, we could export (void :: Functor m => > m > > a -> m ()) from both Control.Monad and F.M.E (if we wanted to). ?If we're > > not willing, then I think it would be a bit more convenient to name them > > different things (so that if you import both modules you don't get a > > name-conflict for using 'void'). > > > > I vote to just name it Control.Monad.ignore . ?Many people independently > > invented the name "ignore" in their own projects. ?Also I suspect the > name > > "void" in FFI has some etymology in C's equivalent, casting expressions > to > > void (eg: (void)printf(something); ) which I doubt most haskell coders > care > > about most of the time? > > > > -Isaac > > _______________________________________________ > > Libraries mailing list > > Libraries@haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From iavor.diatchki at gmail.com Thu Jul 2 18:01:30 2009 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Thu Jul 2 17:43:58 2009 Subject: Adding an ignore function to Control.Monad In-Reply-To: <20090702172217.GE27889@whirlpool.galois.com> References: <4A4C2572.60006@isaac.cedarswampstudios.org> <404396ef0907012326j6ca93absa27d01bcf04eafe1@mail.gmail.com> <7fb8f82f0907020100n4a8bc570q60e9550ec57aef0a@mail.gmail.com> <20090702172217.GE27889@whirlpool.galois.com> Message-ID: <5ab17e790907021501o9676fe8yc296c62407976d5c@mail.gmail.com> Hi, I am not convinced that we need this function in the standard libraries but if people find it useful, then I agree with Don's point that we should stick with "void" because I think that: void readLine read better then ignore readLine -Iavor PS: How about devNull = return ()? Then readLine >> devNull would make sense! :p On Thu, Jul 2, 2009 at 10:22 AM, Don Stewart wrote: > I for one don't like 'ignore' -- it implies to me somehow that the > argument itself is ignored, rather than the result after evaluation. > > Also, 'void' already exists, and is part of a decade-old FFI standard. > > -- Don > > ekmett: >> I agree with Neil on all those points. F.M.E.void has too many things to fix to >> bring it inline with ignore in one go and a worse name. >> >> +1 on adding ignore though. >> >> -Edward Kmett >> >> On Thu, Jul 2, 2009 at 2:26 AM, Neil Mitchell wrote: >> >> ? ? void is the wrong name, wrong type, wrong purpose and wrong module. We >> ? ? could fix all those things, but I think we should just add ignore as >> ? ? previously agreed (+1 for that) >> >> ? ? Thanks, Neil >> >> ? ? On Thu, Jul 2, 2009 at 4:11 AM, Isaac >> ? ? Dupree wrote: >> ? ? > Gwern Branwen wrote: >> ? ? >> >> ? ? >> Since then, Don Stewart has pointed out >> ? ? >> http://hackage.haskell.org/trac/ghc/ticket/3292 that there is a very >> ? ? >> similar function specified in the FFI standard >> ? ? >> http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi/ffise5.html# >> ? ? x8-350005.10 >> ? ? >> - 'void ? ? :: IO a -> IO ()'. >> ? ? > >> ? ? > Are we willing to change (generalize) the type of >> ? ? > Foreign.Marshal.Error.void? ?If so, we could export (void :: Functor m => >> ? ? m >> ? ? > a -> m ()) from both Control.Monad and F.M.E (if we wanted to). ?If we're >> ? ? > not willing, then I think it would be a bit more convenient to name them >> ? ? > different things (so that if you import both modules you don't get a >> ? ? > name-conflict for using 'void'). >> ? ? > >> ? ? > I vote to just name it Control.Monad.ignore . ?Many people independently >> ? ? > invented the name "ignore" in their own projects. ?Also I suspect the >> ? ? name >> ? ? > "void" in FFI has some etymology in C's equivalent, casting expressions >> ? ? to >> ? ? > void (eg: (void)printf(something); ) which I doubt most haskell coders >> ? ? care >> ? ? > about most of the time? >> ? ? > >> ? ? > -Isaac >> ? ? > _______________________________________________ >> ? ? > Libraries mailing list >> ? ? > Libraries@haskell.org >> ? ? > http://www.haskell.org/mailman/listinfo/libraries >> ? ? > >> ? ? _______________________________________________ >> ? ? Libraries mailing list >> ? ? Libraries@haskell.org >> ? ? http://www.haskell.org/mailman/listinfo/libraries >> >> > >> _______________________________________________ >> Libraries mailing list >> Libraries@haskell.org >> http://www.haskell.org/mailman/listinfo/libraries > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From judah.jacobson at gmail.com Thu Jul 2 18:04:16 2009 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Thu Jul 2 17:47:04 2009 Subject: Proposal #3337: expose Unicode and newline translation from System.IO In-Reply-To: <4A49FF05.3020907@gmail.com> References: <4A49FF05.3020907@gmail.com> Message-ID: <6d74b0d20907021504t166ff564sc148d5eff3d8de90@mail.gmail.com> On Tue, Jun 30, 2009 at 5:03 AM, Simon Marlow wrote: > Ticket: > > ?http://hackage.haskell.org/trac/ghc/ticket/3337 > > For the proposed new additions, see: > > ?* http://www.haskell.org/~simonmar/base/System-IO.html#23 > ? System.IO (Unicode encoding/decoding) > > ?* http://www.haskell.org/~simonmar/base/System-IO.html#25 > ? System.IO (Newline conversion) > > Discussion period: 2 weeks (14 July). Three points: 1) It would be good to have an hGetEncoding function, so that we can temporarily set the encoding of a Handle like stdin without affecting the rest of the program. 2) It looks like your API always throws an error on invalid input; it would be great if there were some way to customize this behavior. Nothing complicated, maybe just an enum which specifies one of the following behaviors: - throw an error - ignore (i.e., drop) invalid bytes/Chars - replace undecodable bytes with u+FFFD and unencodable Chars with '?' My preference for the API change would be to add a function in GHC.IO.Encoding.Iconv; for example, mkTextEncodingError :: String -> ErrorHandling -> IO TextEncoding since this is similar to how GHC.IO.Encoding.Latin1 allows error handling by providing latin1 and latin1_checked as separate encoders. Any more complicated behavior is probably best handled by something like the text package. 3) How hard would it be to get Windows code page support working? I'd like that a lot since it would further simplify the code in Haskeline. I can help out with the implementation if it's just a question of time. Thanks again for taking care of all this, -Judah From duncan.coutts at worc.ox.ac.uk Thu Jul 2 18:17:02 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jul 2 18:18:09 2009 Subject: exposing hidden packages with runghc In-Reply-To: References: <1246450020.7418.1.camel@localhost> Message-ID: <1246573022.7418.25.camel@localhost> On Thu, 2009-07-02 at 14:44 +0100, Iain Barnett wrote: > > 2009/7/1 Duncan Coutts > > > This is on a Debian 5.1 machine with GHC 6.8.2 and 6.8.3 on > it. > > The latest version of cabal-install should work fine there. > > Duncan > > Unless you've actually tried installing it on there lately, then I'd > have to disagree. I've now got GHC 6.10.3 running and Cabal 1.6.0.3, > and all the packages needed for cabal-install, and still, it won't go > on using runghc or ghc to build it. Do you have any more details on that? What problem are you hitting exactly? A log file would help us see what's going on. I did test ghc-6.8 when releasing Cabal-1.6 and cabal-install-0.6.2. Duncan From duncan.coutts at worc.ox.ac.uk Thu Jul 2 18:35:20 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jul 2 18:18:22 2009 Subject: Proposal #3337: expose Unicode and newline translation from System.IO In-Reply-To: <4A49FF05.3020907@gmail.com> References: <4A49FF05.3020907@gmail.com> Message-ID: <1246574120.7418.36.camel@localhost> On Tue, 2009-06-30 at 13:03 +0100, Simon Marlow wrote: > Ticket: > > http://hackage.haskell.org/trac/ghc/ticket/3337 > > For the proposed new additions, see: > > * http://www.haskell.org/~simonmar/base/System-IO.html#23 > System.IO (Unicode encoding/decoding) > > * http://www.haskell.org/~simonmar/base/System-IO.html#25 > System.IO (Newline conversion) > > Discussion period: 2 weeks (14 July). A couple things we brought up at the ghc irc meeting yesterday: * UTF-8 with or without BOM? or variants utf8_bom. Do we need all three variants: (pass through bom, produce no bom) -- raw utf8 (accept and ignore bom, produce bom) -- utf8 with bom (accept and ignore bom, produce no bom) -- permissive After thinking about it a bit, I think we can get away with just the existing utf8 and a utf8_bom that accepts a bom and produces a bom. The reason is that to get the third behaviour you just read with utf8_bom and write with utf8. Most operations on text files are read or write of the whole file, not read/write on a single file. * For the moment we are not publicly exposing the TextEncoding type. Later we may want to consider making TextEncoding pure (using ST) and share it for pure conversions String/Text <-> ByteString. Duncan From marlowsd at gmail.com Fri Jul 3 04:23:48 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Jul 3 04:06:21 2009 Subject: Proposal #3337: expose Unicode and newline translation from System.IO In-Reply-To: <6d74b0d20907021504t166ff564sc148d5eff3d8de90@mail.gmail.com> References: <4A49FF05.3020907@gmail.com> <6d74b0d20907021504t166ff564sc148d5eff3d8de90@mail.gmail.com> Message-ID: <4A4DC014.8060909@gmail.com> On 02/07/2009 23:04, Judah Jacobson wrote: > On Tue, Jun 30, 2009 at 5:03 AM, Simon Marlow wrote: >> Ticket: >> >> http://hackage.haskell.org/trac/ghc/ticket/3337 >> >> For the proposed new additions, see: >> >> * http://www.haskell.org/~simonmar/base/System-IO.html#23 >> System.IO (Unicode encoding/decoding) >> >> * http://www.haskell.org/~simonmar/base/System-IO.html#25 >> System.IO (Newline conversion) >> >> Discussion period: 2 weeks (14 July). > > Three points: > > 1) It would be good to have an hGetEncoding function, so that we can > temporarily set the encoding of a Handle like stdin without affecting > the rest of the program. Sure. This might expose the fact that there's no instance Eq TextEncoding, though - I can imagine someone wanting to know whether localeEncoding is UTF-8 or not. Perhaps there should also be textEncodingName :: TextEncoding -> String the idea being that if you pass the String back to mkTextEncoding you get the same encoding. But what about normalisation issues, e.g. "UTF-8" vs. "UTF8"? > 2) It looks like your API always throws an error on invalid input; it > would be great if there were some way to customize this behavior. > Nothing complicated, maybe just an enum which specifies one of the > following behaviors: > > - throw an error > - ignore (i.e., drop) invalid bytes/Chars > - replace undecodable bytes with u+FFFD and unencodable Chars with '?' Yes. > My preference for the API change would be to add a function in > GHC.IO.Encoding.Iconv; for example, > > mkTextEncodingError :: String -> ErrorHandling -> IO TextEncoding So you're suggesting that we implement this only for iconv? That would be easy enough, but then it wouldn't be available on Windows. Another way would be to implement it at the Handle level, by catching encoding/decoding errors from the codec and applying the appropriate workaround. This is a lot more work, of course. > since this is similar to how GHC.IO.Encoding.Latin1 allows error > handling by providing latin1 and latin1_checked as separate encoders. > > Any more complicated behavior is probably best handled by something > like the text package. > > > 3) How hard would it be to get Windows code page support working? I'd > like that a lot since it would further simplify the code in Haskeline. > I can help out with the implementation if it's just a question of > time. Ok, so I did look into this. The problem is that the MultiByteToWideChar API just isn't good enough. 1. It only converts to UTF-16. So I can handle this by using UTF-16 as our internal representation instead of UTF-32, and indeed I have made all the changes for this - there is a #define in the the library. I found it slower than UTF-32, however. 2. If there's a decoding error, you don't get to find out where in the input the error occurred, or do a partial conversion. 3. If there isn't enough room in the target buffer, you don't get to do a partial conversion. 4. Detecting errors is apparently only supported on Win XP and later (MB_ERR_INVALID_CHARS), and for some code pages it isn't supported at all. 2 and 3 are the real show-stoppers. Duncan Coutts found this code from AT&T UWIN that implements iconv in terms of MultiByteToWideChar: http://www.google.com/codesearch/p?hl=en&sa=N&cd=2&ct=rc#0IKL7zWk-JU/src/lib/libast/comp/iconv.c&l=333 notice how it uses a binary search strategy to solve the 3rd problem above. Yuck! This would be the common case if we used this code in the IO library. This is why I wrote our own UTF-{8,16,32} codecs for GHC (borrowing some code from the text package). BTW, Python uses its own automatically-generated codecs for Windows codepages. Maybe we should do that too. Cheers, Simon From lemming at henning-thielemann.de Fri Jul 3 19:08:41 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Jul 3 18:51:13 2009 Subject: proposal #3335: make some Applicative functions into methods, and split off Data.Functor In-Reply-To: <20090630151221.GA7800@soi.city.ac.uk> References: <20090629124545.GA6378@soi.city.ac.uk> <20090630151221.GA7800@soi.city.ac.uk> Message-ID: <4A4E8F79.4000503@henning-thielemann.de> Ross Paterson schrieb: > On Tue, Jun 30, 2009 at 01:37:05PM +0200, Henning Thielemann wrote: >> This sounds like a rather ad-hoc extension of the already complicated >> hierarchy of those category classes. Are there particular examples where >> the specialisation is needed and where it cannot be done by optimizer >> rules? > > Here's one for (<$). In Data.Sequence, I could define > > x <$ s = replicate (size s) x > > (using Louis Wasserman's replicate), which would take O(log n) time and > space, a big improvement over the O(n) version using const and fmap. Would it be reasonable to let the optimizer replace (x <$ s) by (replicate (size s) x) via RULES? From iainspeed at gmail.com Sat Jul 4 08:17:35 2009 From: iainspeed at gmail.com (Iain Barnett) Date: Sat Jul 4 07:59:59 2009 Subject: exposing hidden packages with runghc In-Reply-To: <1246573022.7418.25.camel@localhost> References: <1246450020.7418.1.camel@localhost> <1246573022.7418.25.camel@localhost> Message-ID: 2009/7/2 Duncan Coutts > > Do you have any more details on that? What problem are you hitting > exactly? A log file would help us see what's going on. I did test > ghc-6.8 when releasing Cabal-1.6 and cabal-install-0.6.2. > > Duncan > > Which log files would be helpful? From looking at "ps ax" when it was running it seems that the linking (ld) part of the install is the bit that takes a long time. About 8hrs on this machine, whether I used 1. ghc --make Setup 2. ./Setup configure --user 3. ./Setup build or subsequently 1. ./dist/build/cabal/cabal update 2. ./dist/build/cabal/cabal install cabal-install Just let me know what you need, and I'll be happy to try a fresh install to recreate the problem if needed - once I've backed up this one! Iain -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090704/8beff163/attachment.html From duncan.coutts at worc.ox.ac.uk Sat Jul 4 09:37:21 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Jul 4 10:48:27 2009 Subject: exposing hidden packages with runghc In-Reply-To: References: <1246450020.7418.1.camel@localhost> <1246573022.7418.25.camel@localhost> Message-ID: <1246714641.7418.100.camel@localhost> On Sat, 2009-07-04 at 13:17 +0100, Iain Barnett wrote: > 2009/7/2 Duncan Coutts > Do you have any more details on that? What problem are you > hitting > exactly? A log file would help us see what's going on. I did > test > ghc-6.8 when releasing Cabal-1.6 and cabal-install-0.6.2. > > Duncan > > Which log files would be helpful? From looking at "ps ax" when it was > running it seems that the linking (ld) part of the install is the bit > that takes a long time. About 8hrs on this machine, Wow. That's crazy. I've never seen that before. It should be a few seconds at most, especially since it's not using "split-objs". > whether I used > 1. ghc --make Setup > 2. ./Setup configure --user > 3. ./Setup build > or subsequently > 1. ./dist/build/cabal/cabal update > 2. ./dist/build/cabal/cabal install cabal-install > > Just let me know what you need, and I'll be happy to try a fresh > install to recreate the problem if needed - once I've backed up this > one! Did you say this was an ordinary Debian install? What version, what hardware platform? What version of binutils was that? Was ld using a massive amount of memory? Was it using an amount of memory that pushed everything into swap? Presumably it's the final link that is taking so long, not compiling and linking Setup.hs ? Duncan From iainspeed at gmail.com Sat Jul 4 14:48:08 2009 From: iainspeed at gmail.com (Iain Barnett) Date: Sat Jul 4 14:30:31 2009 Subject: exposing hidden packages with runghc In-Reply-To: <1246714641.7418.100.camel@localhost> References: <1246450020.7418.1.camel@localhost> <1246573022.7418.25.camel@localhost> <1246714641.7418.100.camel@localhost> Message-ID: 2009/7/4 Duncan Coutts > > Did you say this was an ordinary Debian install? What version, what > hardware platform? > > What version of binutils was that? Was ld using a massive amount of > memory? Was it using an amount of memory that pushed everything into > swap? Presumably it's the final link that is taking so long, not > compiling and linking Setup.hs ? > > Duncan > > Quick answers are yes, ordinary install - Debian 5.1 i386, I chose the basic workstation and desktop installs that are the defaults, nothing fancy. I used the packages for GHC 6.8.2 and then added 6.8.3 and 6.10.3 from source, slow but expected. Cabal 1.6 took hours and hours to install from source. The machine is an old compaq with 2.4Ghz P4 and 40Gb drive with lots of space, since I only just installed it, and 256Mb RAM. I know it's not a fast machine, but still... nothing else takes 8+ hrs to install! I didn't get any memory usage off it at the time because the whole machine was so locked up I could barely type, so "ps ax" was as far as I got before cursing, using "renice" to up the priorities, and then turn off the screen and leave it till it finished. binutils is version... GNU ld (GNU Binutils for Debian) 2.18.0.20080103 I reinstalled all the obvious things like gcc and, oh, this is better - Reinstalled the following packages: binutils (2.18.1~cvs20080103-7) gcc (4:4.3.2-2) gcc-4.1 (4.1.2-25) gcc-4.3 (4.3.2-1.1) pkg-config (0.22-1) Tomorrow I'll start another install and save some of the output for you. If there's any commands in particular you want me to pick up then let me know. Iain -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090704/e01dae4c/attachment.html From igloo at earth.li Sun Jul 5 08:15:13 2009 From: igloo at earth.li (Ian Lynagh) Date: Sun Jul 5 07:57:34 2009 Subject: Proposal #3337: expose Unicode and newline translation from System.IO In-Reply-To: <4A49FF05.3020907@gmail.com> References: <4A49FF05.3020907@gmail.com> Message-ID: <20090705121513.GA1479@matrix.chaos.earth.li> On Tue, Jun 30, 2009 at 01:03:17PM +0100, Simon Marlow wrote: > > * http://www.haskell.org/~simonmar/base/System-IO.html#23 > System.IO (Unicode encoding/decoding) Is it possible to make an availableEncodings :: IO [(String, TextEncoding)] ? Also, mkTextEncoding says that it throws an isDoesNotExistError if the named encoding doesn't exist, but the code in base at least looks like it throws InvalidArgument on Windows, and nothing on other platforms. Perhaps it's different in your tree, though. Thanks Ian From judah.jacobson at gmail.com Sun Jul 5 14:48:29 2009 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Sun Jul 5 14:31:09 2009 Subject: Proposal #3337: expose Unicode and newline translation from System.IO In-Reply-To: <4A4DC014.8060909@gmail.com> References: <4A49FF05.3020907@gmail.com> <6d74b0d20907021504t166ff564sc148d5eff3d8de90@mail.gmail.com> <4A4DC014.8060909@gmail.com> Message-ID: <6d74b0d20907051148i46ad5e0du965b7da7d211a57f@mail.gmail.com> On Fri, Jul 3, 2009 at 1:23 AM, Simon Marlow wrote: > On 02/07/2009 23:04, Judah Jacobson wrote: >> >> On Tue, Jun 30, 2009 at 5:03 AM, Simon Marlow ?wrote: >>> >>> Ticket: >>> >>> ?http://hackage.haskell.org/trac/ghc/ticket/3337 >>> >>> For the proposed new additions, see: >>> >>> ?* http://www.haskell.org/~simonmar/base/System-IO.html#23 >>> ? System.IO (Unicode encoding/decoding) >>> >>> ?* http://www.haskell.org/~simonmar/base/System-IO.html#25 >>> ? System.IO (Newline conversion) >>> >>> Discussion period: 2 weeks (14 July). >> >> >> 3) How hard would it be to get Windows code page support working? ?I'd >> like that a lot since it would further simplify the code in Haskeline. >> ?I can help out with the implementation if it's just a question of >> time. > > Ok, so I did look into this. ?The problem is that the MultiByteToWideChar > API just isn't good enough. > [...] > BTW, Python uses its own automatically-generated codecs for Windows > codepages. ?Maybe we should do that too. That approach seems best; and it would be a nice small step towards a pure Haskell replacement for libiconv. I've started working on this. -Judah From ml at isaac.cedarswampstudios.org Sun Jul 5 23:45:31 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Sun Jul 5 23:27:58 2009 Subject: Documentation design Message-ID: <4A51735B.8040901@isaac.cedarswampstudios.org> (for reference, here's the blog-post I wrote that inspired me to ask this list for advice. I'll explain everything in this email anyway though. http://haddock2009.wordpress.com/2009/06/23/how-to-navigate-your-code/ ) My challenge: getting to know an existing code-base quickly and easily, so that I can hack on it. Haddock and HsColour are already pretty helpful at this, but they could be more helpful. (haddock with --ignore-all-exports, i.e. cabal haddock --internal, especially) My dream situation: both haddock-pages and hscolour-pages would be super-hyperlinked and super-readable. For example, haddock would list all a module's definitions, not just its exports. In HsColoured source, every identifier would link to its definition or the haddockumentation of its definition. and so forth. It would be so much easier to generate and browse this in HTML, than to get an IDE working, and it would be so much more readable than a mere text-editor (even with syntax hilighting) and quicker clicking on hyperlinks than grepping for everything. Actually I don't have the resources to worry about designing any HsColour stuff right now (its current design is mainly just a lexeme highlighter). But, with your advices, I can design an improvement on Haddock's ignore-exports mode, which currently has a few shortcomings: 1. you can't tell which identifiers in a module are exported 2. it doesn't document a module's re-exports at all 3. it still obeys {-# OPTIONS_HADDOCK hide #-} et al, even when they're not appropriate for reading documentation of internals 4. 2+3 means that some things may be found nowhere in the documentation at all! Not quite satisfying for something invoked by `cabal haddock --internal`. (Here's a haddock-generated page you can look at so you can figure out the formatting-details I'll be describing: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-List.html and its source code http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/Data-List.html ) The ideal haddockumentation-formatting for this purpose isn't quite obvious though. For example, sometimes you want to think about a module in terms of its abstract interface, but sometimes you want to figure out how it's implemented (without reverting completely to text based code browsing). Maybe a compromise of some sort would be good. so... Here's a proposal, for a new mode (`haddock --all-internal`?, to be invoked by `cabal haddock --internal` rather than --internal's current effect of ignore-all-exports) : Files with no explicit export list can be treated as-is anyway. For all files that have an explicit export list, generate the synopsis-of-exports near the top, as usual. But have the index link, generally, to where functions are originally defined (modulo being from a non-internally-documented separate package, where it should link to the appropriate place), and have the fuller documentation below be a compilation of the identifiers *defined* in this module. Actually that would need some revision because the sections and subsections -- *, -- **, etc. defined in the export-list in the .hs, actually are displayed 1. above the table of contents, linking to places in 2. the full list of definitions. Which might be defined in the module in a different order than they're listed in the export list. Why not add the sections into the synopsis? In this case, instead of adding them to the main doc section. But hmm... in ordinary non-internal documentation, would it be nice to *additionally* have the sections marked in the synopsis (in addition to in the Contents and in the main docs section)? Maybe this mode should also abstain from "hiding" any module, because that would cause missing docs. Etc. Questions? Comments? Opinions? Does anyone want this feature, and/or not think it's particularly useful? -Isaac From jnf at arcor.de Mon Jul 6 04:57:35 2009 From: jnf at arcor.de (jutaro) Date: Mon Jul 6 04:39:53 2009 Subject: Documentation design In-Reply-To: <4A51735B.8040901@isaac.cedarswampstudios.org> References: <4A51735B.8040901@isaac.cedarswampstudios.org> Message-ID: <24351949.post@talk.nabble.com> Have you tried Leksah? I guess it would help you a lot with your task. J?rgen Isaac Dupree-3 wrote: > > (for reference, here's the blog-post I wrote that inspired me to ask > this list for advice. I'll explain everything in this email anyway > though. > http://haddock2009.wordpress.com/2009/06/23/how-to-navigate-your-code/ > ) > > My challenge: getting to know an existing code-base quickly and easily, > so that I can hack on it. Haddock and HsColour are already pretty > helpful at this, but they could be more helpful. (haddock with > --ignore-all-exports, i.e. cabal haddock --internal, especially) > > My dream situation: both haddock-pages and hscolour-pages would be > super-hyperlinked and super-readable. For example, haddock would list > all a module's definitions, not just its exports. In HsColoured source, > every identifier would link to its definition or the haddockumentation > of its definition. and so forth. It would be so much easier to generate > and browse this in HTML, than to get an IDE working, and it would be so > much more readable than a mere text-editor (even with syntax hilighting) > and quicker clicking on hyperlinks than grepping for everything. > > Actually I don't have the resources to worry about designing any > HsColour stuff right now (its current design is mainly just a lexeme > highlighter). But, with your advices, I can design an improvement on > Haddock's ignore-exports mode, which currently has a few shortcomings: > 1. you can't tell which identifiers in a module are exported > 2. it doesn't document a module's re-exports at all > 3. it still obeys {-# OPTIONS_HADDOCK hide #-} et al, even when they're > not appropriate for reading documentation of internals > 4. 2+3 means that some things may be found nowhere in the documentation > at all! Not quite satisfying for something invoked by `cabal haddock > --internal`. > > (Here's a haddock-generated page you can look at so you can figure out > the formatting-details I'll be describing: > http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-List.html > and its source code > http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/Data-List.html > ) > > The ideal haddockumentation-formatting for this purpose isn't quite > obvious though. For example, sometimes you want to think about a module > in terms of its abstract interface, but sometimes you want to figure out > how it's implemented (without reverting completely to text based code > browsing). Maybe a compromise of some sort would be good. so... > > Here's a proposal, for a new mode (`haddock --all-internal`?, to be > invoked by `cabal haddock --internal` rather than --internal's current > effect of ignore-all-exports) : > > Files with no explicit export list can be treated as-is anyway. > > For all files that have an explicit export list, generate the > synopsis-of-exports near the top, as usual. But have the index link, > generally, to where functions are originally defined (modulo being from > a non-internally-documented separate package, where it should link to > the appropriate place), and have the fuller documentation below be a > compilation of the identifiers *defined* in this module. > > Actually that would need some revision because the sections and > subsections -- *, -- **, etc. defined in the export-list in the .hs, > actually are displayed > 1. above the table of contents, linking to places in > 2. the full list of definitions. Which might be defined in the module > in a different order than they're listed in the export list. > Why not add the sections into the synopsis? In this case, instead of > adding them to the main doc section. But hmm... in ordinary > non-internal documentation, would it be nice to *additionally* have the > sections marked in the synopsis (in addition to in the Contents and in > the main docs section)? > > Maybe this mode should also abstain from "hiding" any module, because > that would cause missing docs. Etc. > > Questions? Comments? Opinions? Does anyone want this feature, and/or not > think it's particularly useful? > > -Isaac > > > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -- View this message in context: http://www.nabble.com/Documentation-design-tp24349398p24351949.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. From stefan at cs.uu.nl Mon Jul 6 06:09:55 2009 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Mon Jul 6 06:53:06 2009 Subject: Monoid instances for mtl Message-ID: Hi all, On a number of occasions I found myself declaring simple instances like instance Monoid a => Monoid (State s a) where mzero = return mzero mappend = liftM2 mappend that make my life considerably easier. Would it be a good idea to add such instances to the Monad Transformer Library? Of course, one could ask where to stop---but for me it make sense to always add sensible instances of the classes from base to a given library. Cheers, Stefan From Malcolm.Wallace at cs.york.ac.uk Mon Jul 6 09:15:57 2009 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Mon Jul 6 08:58:19 2009 Subject: exposing hidden packages with runghc In-Reply-To: References: <1246450020.7418.1.camel@localhost> <1246573022.7418.25.camel@localhost> <1246714641.7418.100.camel@localhost> Message-ID: <03DF48CF-DE0F-4E8E-828E-7111480A3A95@cs.york.ac.uk> > The machine is an old compaq with 2.4Ghz P4 and 40Gb drive with lots > of space, since I only just installed it, and 256Mb RAM. > > ... the whole machine was so locked up I could barely type ... There is your answer I think - the physical memory is too small, and the machine was thrashing the swapspace. When that happens, it easily adds several orders of magnitude to the time taken to get anything done. Regards, Malcolm From marlowsd at gmail.com Mon Jul 6 09:39:34 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Jul 6 09:21:57 2009 Subject: Proposal #3337: expose Unicode and newline translation from System.IO In-Reply-To: <20090705121513.GA1479@matrix.chaos.earth.li> References: <4A49FF05.3020907@gmail.com> <20090705121513.GA1479@matrix.chaos.earth.li> Message-ID: <4A51FE96.4070908@gmail.com> On 05/07/2009 13:15, Ian Lynagh wrote: > On Tue, Jun 30, 2009 at 01:03:17PM +0100, Simon Marlow wrote: >> * http://www.haskell.org/~simonmar/base/System-IO.html#23 >> System.IO (Unicode encoding/decoding) > > Is it possible to make an > availableEncodings :: IO [(String, TextEncoding)] > ? No way that I know of. iconv doesn't give you a way to enumerate the available encodings. > Also, mkTextEncoding says that it throws an isDoesNotExistError if the > named encoding doesn't exist, but the code in base at least looks like > it throws InvalidArgument on Windows, and nothing on other platforms. > Perhaps it's different in your tree, though. It throws NoSuchThing on Windows: mkTextEncoding e = ioException (IOError Nothing NoSuchThing "mkTextEncoding" ("unknown encoding:" ++ e) Nothing Nothing) but on Unix, you're right, there's no exception until the encoding is instantiated, which happens when a Handle is opened. I'll look into fixing this. Cheers, Simon From naesten at gmail.com Mon Jul 6 17:30:34 2009 From: naesten at gmail.com (Samuel Bronson) Date: Mon Jul 6 17:13:07 2009 Subject: what about moving the record system to an addendum? Message-ID: <878wj1lcsl.wl%naesten@gmail.com> According to , ticket #99 was rejected, but the tickets own page, , says "probably yes". Which is it? I was about to propose this myself, but decided to check the trac just in case it had already been proposed, Haskell being so popular with smart people and all, and was at first rather disappointed and ready to write an angry rant to the list, then rather confused when I noticed the ticket's page said almost the exact opposite of the Status page. In particular, I want records to be considered an extension to Haskell', to be implemented only by compilers that care, and even then only allowed with a LANGUAGE pragma like this: {-# LANGUAGE TraditionalRecordSyntax #-} For pre-Haskell' compilers, we would want something like: {-# LANGUAGE NoTraditionalRecordSyntax #-} which would mean extending the LANGUAGE pragma to support turning extensions off by adding/removing a No from the front of it. Hmm, is it really the case that nobody has proposed LANGUAGE pragmas for Haskell'? I don't see them listed on the Status page. I guess the work involved here is basically: (a) Go through Haskell 98, find all the parts that talk specifically about record syntax, and write up the list of such places. (b) Implement this in GHC: (c) Add support for negating extension names by adding/removing No in front of extension names to Cabal: (d) Add {-# LANGUAGE #-} to Haskell' What do you folks think? From duncan.coutts at worc.ox.ac.uk Mon Jul 6 18:15:42 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Jul 6 19:19:32 2009 Subject: what about moving the record system to an addendum? In-Reply-To: <878wj1lcsl.wl%naesten@gmail.com> References: <878wj1lcsl.wl%naesten@gmail.com> Message-ID: <1246918542.22466.163.camel@localhost> On Mon, 2009-07-06 at 17:30 -0400, Samuel Bronson wrote: > According to , > ticket #99 was rejected, but the tickets own page, > , says > "probably yes". Which is it? > > I was about to propose this myself, but decided to check the trac just > in case it had already been proposed, Haskell being so popular with > smart people and all, and was at first rather disappointed and ready > to write an angry rant to the list, then rather confused when I > noticed the ticket's page said almost the exact opposite of the Status > page. > > In particular, I want records to be considered an extension to > Haskell', to be implemented only by compilers that care, and even then > only allowed with a LANGUAGE pragma like this: > > {-# LANGUAGE TraditionalRecordSyntax #-} > > For pre-Haskell' compilers, we would want something like: > > {-# LANGUAGE NoTraditionalRecordSyntax #-} > > which would mean extending the LANGUAGE pragma to support turning > extensions off by adding/removing a No from the front of it. The motivation I suppose is so that people can experiment with other record systems as extensions without having to worry so much about the syntax clashing with the existing syntax. It would have to be clear that it may not be possible to use certain combinations of extensions together. In particular TraditionalRecordSyntax with some future alternative record extension. > Hmm, is it really the case that nobody has proposed LANGUAGE pragmas for > Haskell'? I don't see them listed on the Status page. This we certainly need to do. It's the primary mechanism by which we allow flexibility in the language without breaking all existing code (by letting modules declare which language features they want to turn on or off). For one thing the spec currently says that pragmas cannot change the semantics of the program. That would have to read "apart from the LANGUAGE pragma". Duncan From john at repetae.net Mon Jul 6 21:28:54 2009 From: john at repetae.net (John Meacham) Date: Mon Jul 6 21:11:16 2009 Subject: what about moving the record system to an addendum? In-Reply-To: <878wj1lcsl.wl%naesten@gmail.com> References: <878wj1lcsl.wl%naesten@gmail.com> Message-ID: <20090707012854.GD4430@sliver.repetae.net> Well, without a replacement, it seems odd to remove it. Also, Haskell currently doesn't _have_ a record syntax (I think it was always a misnomer to call it that) it has 'labeled fields'. None of the proposed record syntaxes fit the same niche as labeled fields so I don't see them going away even if a record syntax is added to haskell in the future. I would like to see the simple modifications to the record syntax listed on this page though http://hackage.haskell.org/trac/haskell-prime/wiki/ExistingRecords and a reworking of the standard to not refer to the current system as a 'record syntax' but rather a 'labeled fields' syntax. John -- John Meacham - ?repetae.net?john? - http://notanumber.net/ From lemming at henning-thielemann.de Tue Jul 7 05:49:11 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Jul 7 05:31:29 2009 Subject: Monoid instances for mtl In-Reply-To: References: Message-ID: On Mon, 6 Jul 2009, Stefan Holdermans wrote: > Hi all, > > On a number of occasions I found myself declaring simple instances like > > instance Monoid a => Monoid (State s a) where > mzero = return mzero > mappend = liftM2 mappend > > that make my life considerably easier. Would it be a good idea to add such > instances to the Monad Transformer Library? ... and to 'transformers'. However, in 'transformers' we had to define it for StateT, since (State s) is a synonym for (StateT s Identity). But I think this is a good idea anyway. I also need this instance occasionally and had written a custom data type for this purpose: http://hackage.haskell.org/packages/archive/monoid-transformer/0.0.1/doc/html/Data-Monoid-State.html Since it does only need Applicative functionality it can be defined for all other types in MTL. From duncan.coutts at worc.ox.ac.uk Tue Jul 7 05:40:04 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jul 7 06:37:40 2009 Subject: what about moving the record system to an addendum? In-Reply-To: <20090707012854.GD4430@sliver.repetae.net> References: <878wj1lcsl.wl%naesten@gmail.com> <20090707012854.GD4430@sliver.repetae.net> Message-ID: <1246959604.22466.711.camel@localhost> On Mon, 2009-07-06 at 18:28 -0700, John Meacham wrote: > Well, without a replacement, it seems odd to remove it. Also, Haskell > currently doesn't _have_ a record syntax (I think it was always a > misnomer to call it that) it has 'labeled fields'. None of the proposed > record syntaxes fit the same niche as labeled fields so I don't see them > going away even if a record syntax is added to haskell in the future. The people proposing this can correct me if I'm wrong but my understanding of their motivation is not to remove record syntax or immediately to replace it, but to make it easier to experiment with replacements by making the existing labelled fields syntax a modular part of the language that can be turned on or off (like the FFI). I'm not sure that I agree that it's the best approach but it is one idea to try and break the current impasse. It seems currently we cannot experiment with new record systems because they inevitably clash with the current labelled fields and thus nothing changes. Duncan From Malcolm.Wallace at cs.york.ac.uk Tue Jul 7 06:57:46 2009 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Jul 7 06:40:41 2009 Subject: what about moving the record system to an addendum? In-Reply-To: <20090707012854.GD4430@sliver.repetae.net> References: <878wj1lcsl.wl%naesten@gmail.com> <20090707012854.GD4430@sliver.repetae.net> Message-ID: On 7 Jul 2009, at 02:28, John Meacham wrote: > Haskell currently doesn't _have_ a record syntax (I think it was > always a > misnomer to call it that) it has 'labeled fields'. ... > > and a reworking of the standard to not refer to the current system > as a > 'record syntax' but rather a 'labeled fields' syntax. I strongly agree with the latter. In fact, I was under the impression that the Report already avoided the term "record syntax" completely, but checking just now showed 6 distinct occurrences. Regards, Malcolm From ml at isaac.cedarswampstudios.org Tue Jul 7 10:08:08 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Tue Jul 7 09:50:30 2009 Subject: what about moving the record system to an addendum? In-Reply-To: References: <878wj1lcsl.wl%naesten@gmail.com> <20090707012854.GD4430@sliver.repetae.net> Message-ID: <4A5356C8.2080805@isaac.cedarswampstudios.org> Malcolm Wallace wrote: > > On 7 Jul 2009, at 02:28, John Meacham wrote: > >> Haskell currently doesn't _have_ a record syntax (I think it was always a >> misnomer to call it that) it has 'labeled fields'. ... >> >> and a reworking of the standard to not refer to the current system as a >> 'record syntax' but rather a 'labeled fields' syntax. > > I strongly agree with the latter. In fact, I was under the impression > that the Report already avoided the term "record syntax" completely, but > checking just now showed 6 distinct occurrences. ah hah. Existing extension names: NamedFieldPuns (was erroneously "RecordPuns" in GHC for a release) RecordWildCards, DisambiguateRecordFields this "extension" could be named NamedFields. (then giving the lie to the above new names which maybe ought to be more like FieldWildCards and DisambiguateNamedFields(DisambiguateFieldNames?)) Also there is "ExtensibleRecords" which I guess refers to Hugs' TRex? -Isaac From ravi at bluespec.com Tue Jul 7 10:28:11 2009 From: ravi at bluespec.com (Ravi Nanavati) Date: Tue Jul 7 10:10:29 2009 Subject: what about moving the record system to an addendum? In-Reply-To: <1246959604.22466.711.camel@localhost> References: <878wj1lcsl.wl%naesten@gmail.com> <20090707012854.GD4430@sliver.repetae.net> <1246959604.22466.711.camel@localhost> Message-ID: <7b977d860907070728i626edd05oed4c37f4f97e6b03@mail.gmail.com> 2009/7/7 Duncan Coutts : > On Mon, 2009-07-06 at 18:28 -0700, John Meacham wrote: >> Well, without a replacement, it seems odd to remove it. Also, Haskell >> currently doesn't _have_ a record syntax (I think it was always a >> misnomer to call it that) it has 'labeled fields'. None of the proposed >> record syntaxes fit the same niche as labeled fields so I don't see them >> going away even if a record syntax is added to haskell in the future. > > The people proposing this can correct me if I'm wrong but my > understanding of their motivation is not to remove record syntax or > immediately to replace it, but to make it easier to experiment with > replacements by making the existing labelled fields syntax a modular > part of the language that can be turned on or off (like the FFI). > > I'm not sure that I agree that it's the best approach but it is one idea > to try and break the current impasse. It seems currently we cannot > experiment with new record systems because they inevitably clash with > the current labelled fields and thus nothing changes. I think it is a powerful approach to try and break the current impasse for the following reasons: 1. Once implemented, Hackage and Cabal will soon give us accurate data on what publicly available Haskell code does and does not depend on NamedFields/TraditionalRecordSyntax/WhateverWeEndUpCallingIt 2. Once deprecated, people will be encouraged to not depend on the traditional record syntax where the cost of avoiding it is small (I'm thinking of situations like the mtl-accessors / run functions where the traditional syntax is saving something like one function definition). 3. Champions of alternative record syntaxes will know what on Hackage they can use out-of-the-box and what things they'd want to consider re-writing as examples of how their approach is superior. Does anyone have a concrete dea of what it would take to carve out the existing syntax as an addendum? Thanks, - Ravi From iavor.diatchki at gmail.com Tue Jul 7 17:33:00 2009 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue Jul 7 17:15:17 2009 Subject: what about moving the record system to an addendum? In-Reply-To: <7b977d860907070728i626edd05oed4c37f4f97e6b03@mail.gmail.com> References: <878wj1lcsl.wl%naesten@gmail.com> <20090707012854.GD4430@sliver.repetae.net> <1246959604.22466.711.camel@localhost> <7b977d860907070728i626edd05oed4c37f4f97e6b03@mail.gmail.com> Message-ID: <5ab17e790907071433m505d8a66j6e455e51f57bbad3@mail.gmail.com> Hello, I do not think that we should remove the current record/named fields syntax, at least for the moment. I use it a lot, and I do not want to add extra pragmas or "extensions" to my cabal file. In fact, one of the purposes of Haskell', the way I understand it, is exactly to just choose a stable set of extensions and give a name to them (so decrease, not increase the number of pragmas). I think that a new reocrd/label system is way beyond the scope of Haskell'. If people want to experiment with new record systems they may already do so, by defining a new extension. A case in point is the Trex record system, which is implemented in Hugs. -Iavor 2009/7/7 Ravi Nanavati : > 2009/7/7 Duncan Coutts : >> On Mon, 2009-07-06 at 18:28 -0700, John Meacham wrote: >>> Well, without a replacement, it seems odd to remove it. Also, Haskell >>> currently doesn't _have_ a record syntax (I think it was always a >>> misnomer to call it that) it has 'labeled fields'. None of the proposed >>> record syntaxes fit the same niche as labeled fields so I don't see them >>> going away even if a record syntax is added to haskell in the future. >> >> The people proposing this can correct me if I'm wrong but my >> understanding of their motivation is not to remove record syntax or >> immediately to replace it, but to make it easier to experiment with >> replacements by making the existing labelled fields syntax a modular >> part of the language that can be turned on or off (like the FFI). >> >> I'm not sure that I agree that it's the best approach but it is one idea >> to try and break the current impasse. It seems currently we cannot >> experiment with new record systems because they inevitably clash with >> the current labelled fields and thus nothing changes. > > I think it is a powerful approach to try and break the current impasse > for the following reasons: > > 1. Once implemented, Hackage and Cabal will soon give us accurate data > on what publicly available Haskell code does and does not depend on > NamedFields/TraditionalRecordSyntax/WhateverWeEndUpCallingIt > 2. Once deprecated, people will be encouraged to not depend on the > traditional record syntax where the cost of avoiding it is small (I'm > thinking of situations like the mtl-accessors / run functions where > the traditional syntax is saving something like one function > definition). > 3. Champions of alternative record syntaxes will know what on Hackage > they can use out-of-the-box and what things they'd want to consider > re-writing as examples of how their approach is superior. > > Does anyone have a concrete dea of what it would take to carve out the > existing syntax as an addendum? > > Thanks, > > ?- Ravi > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > From john at repetae.net Tue Jul 7 17:33:57 2009 From: john at repetae.net (John Meacham) Date: Tue Jul 7 17:16:17 2009 Subject: what about moving the record system to an addendum? In-Reply-To: <7b977d860907070728i626edd05oed4c37f4f97e6b03@mail.gmail.com> References: <878wj1lcsl.wl%naesten@gmail.com> <20090707012854.GD4430@sliver.repetae.net> <1246959604.22466.711.camel@localhost> <7b977d860907070728i626edd05oed4c37f4f97e6b03@mail.gmail.com> Message-ID: <20090707213357.GF4430@sliver.repetae.net> On Tue, Jul 07, 2009 at 10:28:11AM -0400, Ravi Nanavati wrote: > 2. Once deprecated, people will be encouraged to not depend on the > traditional record syntax where the cost of avoiding it is small (I'm > thinking of situations like the mtl-accessors / run functions where > the traditional syntax is saving something like one function > definition). > 3. Champions of alternative record syntaxes will know what on Hackage > they can use out-of-the-box and what things they'd want to consider > re-writing as examples of how their approach is superior. Well, that's the problem. I don't want to ever deprecate the named field mechanism as it is completely independent of a record system. You can think of the possibilites as follows. named positional declared LabeledFields DataDeclarations anonymous ???? Tuples So, a record syntax fills the hole of anonymous, named field types. However, we shouldn't do it at the expense of opening another hole with declared, named field types any more than we should dispose of standard data declations in favor of making everything newtypes of tuples. Also, this supports the idea of using parethensis rather than braces for a record mechanism. this would be consistent with tuples in that parens = anonymous. Also, if you just replace braces with parens in the scoped records paper, you get no conflicts with existing syntax. (including named fields) :) John -- John Meacham - ?repetae.net?john? - http://notanumber.net/ From roconnor at theorem.ca Tue Jul 7 21:57:59 2009 From: roconnor at theorem.ca (roconnor@theorem.ca) Date: Tue Jul 7 21:40:12 2009 Subject: define gcd 0 0 = 0 (Ticket #3304) Message-ID: As much as I'd love gcd 0 0 to be 0, the major problem is that this change would contradict the Haskell 98 report. Persumably the Haskell report needs to be changed first. Is there a ticket for this for Haskell prime? I didn't find one. -- Russell O'Connor ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' From roconnor at theorem.ca Tue Jul 7 23:33:25 2009 From: roconnor at theorem.ca (roconnor@theorem.ca) Date: Tue Jul 7 23:15:37 2009 Subject: Adding a newtype EndoCategory to Control.Category (ticket #3362) Message-ID: I suggest adding a wrapper to make (a x x) a Monoid for any Category a and type x. This would be added to Control.Category. newtype EndoCategory a x = EndoCategory { runEndoCategory :: a x x } instance (Category a) => Monoid (EndoCategory a x) where mempty = EndoCategory id mappend (EndoCategory f) (EndoCategory g) = EndoCategory (f . g) -- Russell O'Connor ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' From john at repetae.net Wed Jul 8 00:28:31 2009 From: john at repetae.net (John Meacham) Date: Wed Jul 8 00:10:45 2009 Subject: proposal #3335: make some Applicative functions into methods, and split off Data.Functor In-Reply-To: <4A4E8F79.4000503@henning-thielemann.de> References: <20090629124545.GA6378@soi.city.ac.uk> <20090630151221.GA7800@soi.city.ac.uk> <4A4E8F79.4000503@henning-thielemann.de> Message-ID: <20090708042831.GK4430@sliver.repetae.net> On Sat, Jul 04, 2009 at 01:08:41AM +0200, Henning Thielemann wrote: > Ross Paterson schrieb: > > On Tue, Jun 30, 2009 at 01:37:05PM +0200, Henning Thielemann wrote: > >> This sounds like a rather ad-hoc extension of the already complicated > >> hierarchy of those category classes. Are there particular examples where > >> the specialisation is needed and where it cannot be done by optimizer > >> rules? > > > > Here's one for (<$). In Data.Sequence, I could define > > > > x <$ s = replicate (size s) x > > > > (using Louis Wasserman's replicate), which would take O(log n) time and > > space, a big improvement over the O(n) version using const and fmap. > > Would it be reasonable to let the optimizer replace (x <$ s) by > (replicate (size s) x) via RULES? I don't like using RULES for optimizations that actually change the computational or space complexity of code. The reason being that often the complexity determines whether an algorithm works at all (like whether frisby requires O(n) space or O(1) space, a fundamental difference in functionality). We need control of what algorithms are used, not to rely on an compiler specific extension that may or may not get applied properly. In addition, RULES won't apply to polymorphic functions written on top of the existing ones that call class methods. RULES only apply to the top level interface when they do apply. instance definitions will always be used. John -- John Meacham - ?repetae.net?john? - http://notanumber.net/ From lemming at henning-thielemann.de Wed Jul 8 04:00:07 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Jul 8 03:42:23 2009 Subject: define gcd 0 0 = 0 (Ticket #3304) In-Reply-To: References: Message-ID: On Tue, 7 Jul 2009, roconnor@theorem.ca wrote: > As much as I'd love gcd 0 0 to be 0, the major problem is that this change > would contradict the Haskell 98 report. There was a long thread about this issue some years ago that came to the conclusion that the current behaviour of gcd is algebraically most sound. From ross at soi.city.ac.uk Wed Jul 8 04:02:55 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Jul 8 03:45:07 2009 Subject: Adding a newtype EndoCategory to Control.Category (ticket #3362) In-Reply-To: References: Message-ID: <20090708080255.GB5353@soi.city.ac.uk> On Tue, Jul 07, 2009 at 11:33:25PM -0400, roconnor@theorem.ca wrote: > I suggest adding a wrapper to make (a x x) a Monoid for any Category a > and type x. This would be added to Control.Category. > > newtype EndoCategory a x = EndoCategory { runEndoCategory :: a x x } > > instance (Category a) => Monoid (EndoCategory a x) where > mempty = EndoCategory id > mappend (EndoCategory f) (EndoCategory g) = EndoCategory (f . g) In Data.Monoid there is newtype Endo a = Endo { appEndo :: a -> a } instance Monoid (Endo a) where mempty = Endo id Endo f `mappend` Endo g = Endo (f . g) and (->) is an instance of Category, so perhaps we should generalize Endo. The name EndoCategory seems wrong, as this won't be an instance of Category. Endomorphism? From iainspeed at gmail.com Wed Jul 8 05:29:03 2009 From: iainspeed at gmail.com (Iain Barnett) Date: Wed Jul 8 05:11:18 2009 Subject: exposing hidden packages with runghc In-Reply-To: <03DF48CF-DE0F-4E8E-828E-7111480A3A95@cs.york.ac.uk> References: <1246450020.7418.1.camel@localhost> <1246573022.7418.25.camel@localhost> <1246714641.7418.100.camel@localhost> <03DF48CF-DE0F-4E8E-828E-7111480A3A95@cs.york.ac.uk> Message-ID: 2009/7/6 Malcolm Wallace > The machine is an old compaq with 2.4Ghz P4 and 40Gb drive with lots of >> space, since I only just installed it, and 256Mb RAM. >> >> ... the whole machine was so locked up I could barely type ... >> > > There is your answer I think - the physical memory is too small, and the > machine was thrashing the swapspace. When that happens, it easily adds > several orders of magnitude to the time taken to get anything done. > > As I wrote those words I thought it might be said, but let me put it another way. No other install on this machine has taken anywhere close (i.e. they are all in minutes or 10's of minutes). It's the ONLY one that has had this effect. It's not the physical memory - or if it is, then it's the program's fault for using way too much. Would be nice to have more, of course, but 256 should enough for what I'm doing. Iain -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090708/25046237/attachment-0001.html From lemming at henning-thielemann.de Wed Jul 8 06:05:21 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Jul 8 05:57:59 2009 Subject: define gcd 0 0 = 0 (Ticket #3304) In-Reply-To: <1247044509.3533.8.camel@localhost> References: <1247044509.3533.8.camel@localhost> Message-ID: On Wed, 8 Jul 2009, Steve wrote: > On Wed, 2009-07-08 at 10:00 +0200, Henning Thielemann wrote: >> On Tue, 7 Jul 2009, roconnor@theorem.ca wrote: >> >>> As much as I'd love gcd 0 0 to be 0, the major problem is that this change >>> would contradict the Haskell 98 report. >> >> There was a long thread about this issue some years ago that came to the >> conclusion that the current behaviour of gcd is algebraically most sound. > > I don't believe there was any such conclusion. But if you can provide a > link to the thread it would be interesting to see it. > > There was a long thread about the issue in 2001 that came to the > conclusion that "there is a lot of support for gcd 0 0 = 0" and "The > strong default for H98 is "no change"". > http://www.mail-archive.com/haskell@haskell.org/msg09883.html You are right, I mixed that up. The mail you mention summarizes the thread with the name "gcd 0 0 = 0" http://www.haskell.org/pipermail/haskell/2001-December/008609.html From ekmett at gmail.com Wed Jul 8 09:33:13 2009 From: ekmett at gmail.com (Edward Kmett) Date: Wed Jul 8 09:15:24 2009 Subject: Adding a newtype EndoCategory to Control.Category (ticket #3362) In-Reply-To: <20090708080255.GB5353@soi.city.ac.uk> References: <20090708080255.GB5353@soi.city.ac.uk> Message-ID: <7fb8f82f0907080633r5e1c959co58b4a7f7ac5ec7e@mail.gmail.com> +1 in favor of generalizing Endo in Data.Monoid. In my monoids library I have a Data.Monoid.Categorical that includes a 'GEndo' generalized endomorphism over an arbitrary category and I would love to be able to remove it. -Edward Kmett On Wed, Jul 8, 2009 at 4:02 AM, Ross Paterson wrote: > On Tue, Jul 07, 2009 at 11:33:25PM -0400, roconnor@theorem.ca wrote: > > I suggest adding a wrapper to make (a x x) a Monoid for any Category a > > and type x. This would be added to Control.Category. > > > > newtype EndoCategory a x = EndoCategory { runEndoCategory :: a x x } > > > > instance (Category a) => Monoid (EndoCategory a x) where > > mempty = EndoCategory id > > mappend (EndoCategory f) (EndoCategory g) = EndoCategory (f . g) > > In Data.Monoid there is > > newtype Endo a = Endo { appEndo :: a -> a } > > instance Monoid (Endo a) where > mempty = Endo id > Endo f `mappend` Endo g = Endo (f . g) > > and (->) is an instance of Category, so perhaps we should generalize Endo. > > The name EndoCategory seems wrong, as this won't be an instance of > Category. > Endomorphism? > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090708/e0af3787/attachment.html From kahl at cas.mcmaster.ca Wed Jul 8 09:57:13 2009 From: kahl at cas.mcmaster.ca (kahl@cas.mcmaster.ca) Date: Wed Jul 8 09:39:28 2009 Subject: define gcd 0 0 = 0 (Ticket #3304) In-Reply-To: (message from Henning Thielemann on Wed, 08 Jul 2009 10:00:07 +0200 (CEST)) References: Message-ID: <20090708135713.24272.qmail@schroeder.cas.mcmaster.ca> Henning Thielemann antwortete roconnor@theorem.ca: > > > As much as I'd love gcd 0 0 to be 0, the major problem is that this change > > would contradict the Haskell 98 report. > > There was a long thread about this issue some years ago that came to the > conclusion that the current behaviour of gcd is algebraically most > sound. Huh? Algebraically, gcd is the binary greatest-lower-bound operation in the divisibility ordering of the naturals, or in the divisibility preordering on the integers. In both, 0 is the unique top element (everything divides zero). Therefore, ``gcd 0 0 = 0'' is even ``more algebraically justified'' than ``gcd (-2) (-6) = 2'', which is what both hugs and ghc produce. Wolfram From lemming at henning-thielemann.de Wed Jul 8 10:15:44 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Jul 8 09:58:02 2009 Subject: proposal #3335: make some Applicative functions into method, and split off Data.Functor In-Reply-To: <20090708042831.GK4430@sliver.repetae.net> References: <20090629124545.GA6378@soi.city.ac.uk> <20090630151221.GA7800@soi.city.ac.uk> <4A4E8F79.4000503@henning-thielemann.de> <20090708042831.GK4430@sliver.repetae.net> Message-ID: <4A54AA10.5040201@henning-thielemann.de> John Meacham wrote: > On Sat, Jul 04, 2009 at 01:08:41AM +0200, Henning Thielemann wrote: >> Ross Paterson schrieb: >>> On Tue, Jun 30, 2009 at 01:37:05PM +0200, Henning Thielemann wrote: >>>> This sounds like a rather ad-hoc extension of the already complicated >>>> hierarchy of those category classes. Are there particular examples where >>>> the specialisation is needed and where it cannot be done by optimizer >>>> rules? >>> Here's one for (<$). In Data.Sequence, I could define >>> >>> x <$ s = replicate (size s) x >>> >>> (using Louis Wasserman's replicate), which would take O(log n) time and >>> space, a big improvement over the O(n) version using const and fmap. >> Would it be reasonable to let the optimizer replace (x <$ s) by >> (replicate (size s) x) via RULES? > > I don't like using RULES for optimizations that actually change the > computational or space complexity of code. It was said, that the new methods should equal the default definitions, that is, they cannot be "optimized too much", e.g. the specialized definitions are not allow to produce something defined where the default definition is undefined. That's the situation where RULES are made for. It's sad that application of RULES is so unreliable and maybe that should be seriously improved. However, when doing optimization via type class methods I see the danger that after splitting all standard type classes down to one method per class in the past years we will see another flood of extending the type class by specialized functions, maybe followed by new splits. Maybe such a development is a good thing, but then again, we still have no good tools to keep in sync with all these modifications. From roconnor at theorem.ca Wed Jul 8 14:05:52 2009 From: roconnor at theorem.ca (roconnor@theorem.ca) Date: Wed Jul 8 13:48:04 2009 Subject: Adding a newtype EndoCategory to Control.Category (ticket #3362) In-Reply-To: <7fb8f82f0907080633r5e1c959co58b4a7f7ac5ec7e@mail.gmail.com> References: <20090708080255.GB5353@soi.city.ac.uk> <7fb8f82f0907080633r5e1c959co58b4a7f7ac5ec7e@mail.gmail.com> Message-ID: On Wed, 8 Jul 2009, Edward Kmett wrote: > +1 in favor of generalizing Endo in Data.Monoid. > > In my monoids library I have a Data.Monoid.Categorical that includes a 'GEndo' generalized endomorphism > over an arbitrary category and I would love to be able to remove it. > > -Edward Kmett I was looking for this in your lib, but I didn't find it. Anyhow, I'm also in favour of generalizing Endo. I was being conservitive with my initial proposal. Would we still have to pick a new name and then type Endo a = NewEndoName (->) a ? > In Data.Monoid there is > > ?newtype Endo a = Endo { appEndo :: a -> a } > > ?instance Monoid (Endo a) where > ? ? ? ?mempty = Endo id > ? ? ? ?Endo f `mappend` Endo g = Endo (f . g) > > and (->) is an instance of Category, so perhaps we should generalize Endo. > > The name EndoCategory seems wrong, as this won't be an instance of Category. > Endomorphism? > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > > > -- Russell O'Connor ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' From ekmett at gmail.com Wed Jul 8 15:15:06 2009 From: ekmett at gmail.com (Edward Kmett) Date: Wed Jul 8 14:57:17 2009 Subject: Adding a newtype EndoCategory to Control.Category (ticket #3362) In-Reply-To: References: <20090708080255.GB5353@soi.city.ac.uk> <7fb8f82f0907080633r5e1c959co58b4a7f7ac5ec7e@mail.gmail.com> Message-ID: <7fb8f82f0907081215x22b730e0ia2fe672915251003@mail.gmail.com> Yeah, it would probably have to have a new name because it does have a different kind than the existing Endo. GEndo was the best I could come up with that didn't sound verbose (GeneralizedEndo, CategoricalEndo) or like it was naming the wrong thing (EndoCategory). I'm not wedded to the name by any means. Note: a type synonym, > type Endo = GEndo (->) like you mentioned would work, but has the downside that it may require clients that provided instances for Endo to add TypeSynonymInstances where they previously hadn't and I'm not sure how folks would feel about that. -Edward Kmett On Wed, Jul 8, 2009 at 2:05 PM, wrote: > On Wed, 8 Jul 2009, Edward Kmett wrote: > > +1 in favor of generalizing Endo in Data.Monoid. >> >> In my monoids library I have a Data.Monoid.Categorical that includes a >> 'GEndo' generalized endomorphism >> over an arbitrary category and I would love to be able to remove it. >> >> -Edward Kmett >> > > I was looking for this in your lib, but I didn't find it. > > Anyhow, I'm also in favour of generalizing Endo. I was being conservitive > with my initial proposal. > > Would we still have to pick a new name and then > > type Endo a = NewEndoName (->) a > > ? > > In Data.Monoid there is >> >> newtype Endo a = Endo { appEndo :: a -> a } >> >> instance Monoid (Endo a) where >> mempty = Endo id >> Endo f `mappend` Endo g = Endo (f . g) >> >> and (->) is an instance of Category, so perhaps we should generalize Endo. >> >> The name EndoCategory seems wrong, as this won't be an instance of >> Category. >> Endomorphism? >> _______________________________________________ >> Libraries mailing list >> Libraries@haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> >> >> >> >> > -- > Russell O'Connor > ``All talk about `theft,''' the general counsel of the American Graphophone > Company wrote, ``is the merest claptrap, for there exists no property in > ideas musical, literary or artistic, except as defined by statute.'' > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090708/29cbd498/attachment.html From ml at isaac.cedarswampstudios.org Wed Jul 8 15:50:04 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Wed Jul 8 15:32:31 2009 Subject: Adding a newtype EndoCategory to Control.Category (ticket #3362) In-Reply-To: <7fb8f82f0907081215x22b730e0ia2fe672915251003@mail.gmail.com> References: <20090708080255.GB5353@soi.city.ac.uk> <7fb8f82f0907080633r5e1c959co58b4a7f7ac5ec7e@mail.gmail.com> <7fb8f82f0907081215x22b730e0ia2fe672915251003@mail.gmail.com> Message-ID: <4A54F86C.2000003@isaac.cedarswampstudios.org> Edward Kmett wrote: > Yeah, it would probably have to have a new name because it does have a > different kind than the existing Endo. GEndo was the best I could come up > with that didn't sound verbose (GeneralizedEndo, CategoricalEndo) or like it > was naming the wrong thing (EndoCategory). I'm not wedded to the name by any > means. CatEndo? From roconnor at theorem.ca Wed Jul 8 16:18:47 2009 From: roconnor at theorem.ca (roconnor@theorem.ca) Date: Wed Jul 8 16:00:57 2009 Subject: Adding a newtype EndoCategory to Control.Category (ticket #3362) In-Reply-To: <7fb8f82f0907081215x22b730e0ia2fe672915251003@mail.gmail.com> References: <20090708080255.GB5353@soi.city.ac.uk> <7fb8f82f0907080633r5e1c959co58b4a7f7ac5ec7e@mail.gmail.com> <7fb8f82f0907081215x22b730e0ia2fe672915251003@mail.gmail.com> Message-ID: On Wed, 8 Jul 2009, Edward Kmett wrote: > Yeah, it would probably have to have a new name because it does have a different kind than the existing > Endo. GEndo was the best I could come up with that didn't sound verbose (GeneralizedEndo, CategoricalEndo) > or like it was naming the wrong thing (EndoCategory). I'm not wedded to the name by any means. > > Note: a type synonym, > > > type Endo = GEndo (->) > > like you mentioned would work, but has the downside that it may require clients that provided instances for > Endo to add TypeSynonymInstances where they previously hadn't and I'm not sure how folks would feel about > that. Oh, that is a quite a downside. I wonder if we can get cabal stats on this without difficulty. As for the name, I'd be happy with the EndoMorphism suggestion given. Although it is a bit longish. I'd also be happy with EndoMorph. -- Russell O'Connor ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' From ekmett at gmail.com Wed Jul 8 16:47:04 2009 From: ekmett at gmail.com (Edward Kmett) Date: Wed Jul 8 16:29:15 2009 Subject: Adding a newtype EndoCategory to Control.Category (ticket #3362) In-Reply-To: References: <20090708080255.GB5353@soi.city.ac.uk> <7fb8f82f0907080633r5e1c959co58b4a7f7ac5ec7e@mail.gmail.com> <7fb8f82f0907081215x22b730e0ia2fe672915251003@mail.gmail.com> Message-ID: <7fb8f82f0907081347i4683b1cav7fa27c8a0c822ba7@mail.gmail.com> Not sure I like having the upper case on Morphism in EndoMorphism. Endo is a prefix, not a word. and and Endomorphism is a bit scary and long. Isaac's CatEndo suggestion seems relatively innocuous though. (CFunctor, CMonad, etc. in category-extras Control.Functor.Categorical where all originally CatFunctor, etc.) -Edward Kmett On Wed, Jul 8, 2009 at 4:18 PM, wrote: > On Wed, 8 Jul 2009, Edward Kmett wrote: > > Yeah, it would probably have to have a new name because it does have a >> different kind than the existing >> Endo. GEndo was the best I could come up with that didn't sound verbose >> (GeneralizedEndo, CategoricalEndo) >> or like it was naming the wrong thing (EndoCategory). I'm not wedded to >> the name by any means. >> >> Note: a type synonym, >> >> > type Endo = GEndo (->) >> >> like you mentioned would work, but has the downside that it may require >> clients that provided instances for >> Endo to add TypeSynonymInstances where they previously hadn't and I'm not >> sure how folks would feel about >> that. >> > > Oh, that is a quite a downside. I wonder if we can get cabal stats on this > without difficulty. > > As for the name, I'd be happy with the EndoMorphism suggestion given. > Although it is a bit longish. I'd also be happy with EndoMorph. > > > -- > Russell O'Connor > ``All talk about `theft,''' the general counsel of the American Graphophone > Company wrote, ``is the merest claptrap, for there exists no property in > ideas musical, literary or artistic, except as defined by statute.'' > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090708/d55a8145/attachment.html From roconnor at theorem.ca Wed Jul 8 22:05:31 2009 From: roconnor at theorem.ca (roconnor@theorem.ca) Date: Wed Jul 8 21:47:40 2009 Subject: Adding a newtype EndoCategory to Control.Category (ticket #3362) In-Reply-To: <20090708233140.GA11227@soi.city.ac.uk> References: <20090708080255.GB5353@soi.city.ac.uk> <7fb8f82f0907080633r5e1c959co58b4a7f7ac5ec7e@mail.gmail.com> <7fb8f82f0907081215x22b730e0ia2fe672915251003@mail.gmail.com> <20090708233140.GA11227@soi.city.ac.uk> Message-ID: >> Oh, that is a quite a downside. I wonder if we can get cabal stats on >> this without difficulty. > > The only packages on hackage containing instances for Endo are: > > base > HStringTemplate > monoids > special-functors > TypeCompose Is this few enough that we can make our change? -- Russell O'Connor ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' From rizsotto at gmail.com Thu Jul 9 05:42:20 2009 From: rizsotto at gmail.com (Laszlo Nagy) Date: Thu Jul 9 05:24:29 2009 Subject: random tune Message-ID: <431fb4c10907090242s3307445ci2548bca2e66b3fc0@mail.gmail.com> Hi All, I would like to contribute something useful for the community. I've read through some tickets and found I can't solve any of them. Instead I've looked for small tasks which might help to complete one. One was the #1338 ticket, which mention that random package should use 'time' package instead of 'old-time'. I also run the hlint program against the random library and applied the recommendations. Here are the patches: http://sites.google.com/site/rizsotto/patches/random-time.darcs http://sites.google.com/site/rizsotto/patches/random-hlintclean.darcs Regards, Laszlo From ross at soi.city.ac.uk Thu Jul 9 07:56:15 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Jul 9 07:38:27 2009 Subject: Adding a newtype EndoCategory to Control.Category (ticket #3362) In-Reply-To: References: <20090708080255.GB5353@soi.city.ac.uk> <7fb8f82f0907080633r5e1c959co58b4a7f7ac5ec7e@mail.gmail.com> <7fb8f82f0907081215x22b730e0ia2fe672915251003@mail.gmail.com> <20090708233140.GA11227@soi.city.ac.uk> Message-ID: <20090709115615.GA6038@soi.city.ac.uk> On Wed, Jul 08, 2009 at 10:05:31PM -0400, roconnor@theorem.ca wrote: >> The only packages on hackage containing instances for Endo are: >> >> base >> HStringTemplate >> monoids >> special-functors >> TypeCompose > > Is this few enough that we can make our change? The following additional packages use the current structure of Endo, which would change: collections explicit-exception future happs-hsp-template happstack-server lhc midi monad-ran phooey storablevector synthesizer synthesizer-core xmonad xmonad-contrib yi From ekmett at gmail.com Thu Jul 9 08:28:48 2009 From: ekmett at gmail.com (Edward Kmett) Date: Thu Jul 9 08:10:56 2009 Subject: Adding a newtype EndoCategory to Control.Category (ticket #3362) In-Reply-To: <20090709115615.GA6038@soi.city.ac.uk> References: <20090708080255.GB5353@soi.city.ac.uk> <7fb8f82f0907080633r5e1c959co58b4a7f7ac5ec7e@mail.gmail.com> <7fb8f82f0907081215x22b730e0ia2fe672915251003@mail.gmail.com> <20090708233140.GA11227@soi.city.ac.uk> <20090709115615.GA6038@soi.city.ac.uk> Message-ID: <7fb8f82f0907090528i78c0495aja5765faed0845f0a@mail.gmail.com> Well, of those monoids and monad-ran are mine and I'd happily rerelease them both to work with a new Endo. -Ed On Thu, Jul 9, 2009 at 7:56 AM, Ross Paterson wrote: > On Wed, Jul 08, 2009 at 10:05:31PM -0400, roconnor@theorem.ca wrote: > >> The only packages on hackage containing instances for Endo are: > >> > >> base > >> HStringTemplate > >> monoids > >> special-functors > >> TypeCompose > > > > Is this few enough that we can make our change? > > The following additional packages use the current structure of Endo, > which would change: > > collections > explicit-exception > future > happs-hsp-template > happstack-server > lhc > midi > monad-ran > phooey > storablevector > synthesizer > synthesizer-core > xmonad > xmonad-contrib > yi > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090709/8c4403a2/attachment.html From roconnor at theorem.ca Thu Jul 9 09:13:22 2009 From: roconnor at theorem.ca (roconnor@theorem.ca) Date: Thu Jul 9 08:55:31 2009 Subject: Adding a newtype EndoCategory to Control.Category (ticket #3362) In-Reply-To: <20090709115615.GA6038@soi.city.ac.uk> References: <20090708080255.GB5353@soi.city.ac.uk> <7fb8f82f0907080633r5e1c959co58b4a7f7ac5ec7e@mail.gmail.com> <7fb8f82f0907081215x22b730e0ia2fe672915251003@mail.gmail.com> <20090708233140.GA11227@soi.city.ac.uk> <20090709115615.GA6038@soi.city.ac.uk> Message-ID: On Thu, 9 Jul 2009, Ross Paterson wrote: > On Wed, Jul 08, 2009 at 10:05:31PM -0400, roconnor@theorem.ca wrote: >>> The only packages on hackage containing instances for Endo are: >>> >>> base >>> HStringTemplate >>> monoids >>> special-functors >>> TypeCompose >> >> Is this few enough that we can make our change? > > The following additional packages use the current structure of Endo, > which would change: > > ... Would they really need to change if we did newtype Endomorph a x = Endo { getEndo :: a x x } type Endo = Endomorph (->) I guess it would be kinda confusing if we did that. ... but only a little. :) -- Russell O'Connor ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' From ekmett at gmail.com Thu Jul 9 09:17:52 2009 From: ekmett at gmail.com (Edward Kmett) Date: Thu Jul 9 09:00:02 2009 Subject: Adding a newtype EndoCategory to Control.Category (ticket #3362) In-Reply-To: References: <20090708080255.GB5353@soi.city.ac.uk> <7fb8f82f0907080633r5e1c959co58b4a7f7ac5ec7e@mail.gmail.com> <7fb8f82f0907081215x22b730e0ia2fe672915251003@mail.gmail.com> <20090708233140.GA11227@soi.city.ac.uk> <20090709115615.GA6038@soi.city.ac.uk> Message-ID: <7fb8f82f0907090617n3d69810au359fba9bd260295f@mail.gmail.com> As the devil's advocate I'd like to point out that we could just leave Endo alone, and define its generalized counterpart separately. No worries about TypeSynonymInstances and no hassle. -Edward Kmett On Thu, Jul 9, 2009 at 9:13 AM, wrote: > On Thu, 9 Jul 2009, Ross Paterson wrote: > > On Wed, Jul 08, 2009 at 10:05:31PM -0400, roconnor@theorem.ca wrote: >> >>> The only packages on hackage containing instances for Endo are: >>>> >>>> base >>>> HStringTemplate >>>> monoids >>>> special-functors >>>> TypeCompose >>>> >>> >>> Is this few enough that we can make our change? >>> >> >> The following additional packages use the current structure of Endo, >> which would change: >> >> ... >> > > Would they really need to change if we did > > newtype Endomorph a x = Endo { getEndo :: a x x } > > type Endo = Endomorph (->) > > I guess it would be kinda confusing if we did that. ... but only a little. > :) > > -- > Russell O'Connor > ``All talk about `theft,''' the general counsel of the American Graphophone > Company wrote, ``is the merest claptrap, for there exists no property in > ideas musical, literary or artistic, except as defined by statute.'' > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090709/64afeb82/attachment-0001.html From briqueabraque at yahoo.com Thu Jul 9 10:47:10 2009 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Thu Jul 9 10:29:40 2009 Subject: C includes in packages? Message-ID: Is it possible to provide a C header in a cabal package? Maybe as a template for hs2c? I would like to include a few macros in a base package so that all dependent packages could use then to implement C code. Thanks, Maur?cio From golubovsky at gmail.com Thu Jul 9 12:50:43 2009 From: golubovsky at gmail.com (Dimitry Golubovsky) Date: Thu Jul 9 12:32:52 2009 Subject: Dynamically formed list of modules in a Cabal package? Message-ID: Hi, Is this possible to have a list of modules (in the other-modules field of Cabal package description) be formed dynamically? It is a common situation when a Haskell module in a Cabal package is created as a result of preprocessing e. g. by cpp or hsc2hs. This covers the case of one non-Haskell source and one Haskell module. Another scenario, when ffipkg (or domconv*) is used, results in several files (C headers or IDL files) converted to any unpredictable number of Haskell modules (approx. one per C structure/union in the case of ffipkg, or one per IDL interface in the case of domconv). These modules often have meaningless names (esp. in the case of ffipkg) and are not to be used outside of the package that depends on them. So it is not possible to pre-hardcode them all in the hand-written Cabal file. How can Cabal be instructed to add those modules to the list of modules defined in the "other-modules" field of package description? A possible solution might be to create a "private" package before the "main" package is configured, and include the private package into the list of build-depends of the main package. This approach was used for the webidl** package [1] by adding a pre-configuration hook that goes into a sub-directory and builds the private package out of C library headers [2]. This is not a very good solution because private packages will occupy the global package namespace while not being usable by any package other than their main package. A much better solution (one that I am seeking) would be to tell Cabal at some point (via hook, before the configure step starts) that there are more modules in the package that mentioned in the other-modules field. How can this be done? Thanks for any ideas. -------------------------------------------------------- * for applications that run in a web browser via conversion to Javascript and use IDL-defined DOM interfaces ** this package incorporates an IDL lexer generated with flex and used via FFI [1] http://hackage.haskell.org/package/webidl, also see the build log at http://hackage.haskell.org/packages/archive/webidl/0.1.1/logs/success/ghc-6.10 [2] http://code.haskell.org/yc2js/webidl/Setup.hs -- Dimitry Golubovsky Anywhere on the Web From dons at galois.com Thu Jul 9 13:35:38 2009 From: dons at galois.com (Don Stewart) Date: Thu Jul 9 13:19:45 2009 Subject: C includes in packages? In-Reply-To: References: Message-ID: <20090709173538.GN28909@whirlpool.galois.com> briqueabraque: > Is it possible to provide a C header in a cabal > package? Maybe as a template for hs2c? I would > like to include a few macros in a base package > so that all dependent packages could use then to > implement C code. Yes, certainly. Many packages on hackage include both .h and .c files. From s.clover at gmail.com Thu Jul 9 21:15:37 2009 From: s.clover at gmail.com (Sterling Clover) Date: Thu Jul 9 20:56:07 2009 Subject: Adding a newtype EndoCategory to Control.Category (ticket #3362) In-Reply-To: References: <20090708080255.GB5353@soi.city.ac.uk> <7fb8f82f0907080633r5e1c959co58b4a7f7ac5ec7e@mail.gmail.com> <7fb8f82f0907081215x22b730e0ia2fe672915251003@mail.gmail.com> <20090708233140.GA11227@soi.city.ac.uk> Message-ID: As far as HStringTemplate, I'd have no objections to a more generalized Endo. Cheers, Sterl. On Jul 8, 2009, at 10:05 PM, roconnor@theorem.ca wrote: >>> Oh, that is a quite a downside. I wonder if we can get cabal >>> stats on >>> this without difficulty. >> >> The only packages on hackage containing instances for Endo are: >> >> base >> HStringTemplate >> monoids >> special-functors >> TypeCompose > > Is this few enough that we can make our change? > > -- > Russell O'Connor > ``All talk about `theft,''' the general counsel of the American > Graphophone > Company wrote, ``is the merest claptrap, for there exists no > property in > ideas musical, literary or artistic, except as defined by statute.'' > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From gwern0 at gmail.com Fri Jul 10 22:45:30 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Fri Jul 10 22:27:32 2009 Subject: Adding an ignore function to Control.Monad In-Reply-To: <5ab17e790907021501o9676fe8yc296c62407976d5c@mail.gmail.com> References: <4A4C2572.60006@isaac.cedarswampstudios.org> <404396ef0907012326j6ca93absa27d01bcf04eafe1@mail.gmail.com> <7fb8f82f0907020100n4a8bc570q60e9550ec57aef0a@mail.gmail.com> <20090702172217.GE27889@whirlpool.galois.com> <5ab17e790907021501o9676fe8yc296c62407976d5c@mail.gmail.com> Message-ID: OK, let's apply a little democracy here. Reading back through the thread, I tally the votes: # Nothing David Menendez John Meachem (?) # Just ## Control.Monad.ignore m a -> m () Michael Snoyman Neil Mitchell Isaac Dupree Maur??cio Martijn van Steenbergen ### Control.Monad.ignore f a -> f () Edward Kmett ## Control.Monad.void m a -> m () Don Stewart Iavor Diatchki -- gwern From dons at galois.com Fri Jul 10 23:10:32 2009 From: dons at galois.com (Don Stewart) Date: Fri Jul 10 22:54:35 2009 Subject: Adding an ignore function to Control.Monad In-Reply-To: References: <4A4C2572.60006@isaac.cedarswampstudios.org> <404396ef0907012326j6ca93absa27d01bcf04eafe1@mail.gmail.com> <7fb8f82f0907020100n4a8bc570q60e9550ec57aef0a@mail.gmail.com> <20090702172217.GE27889@whirlpool.galois.com> <5ab17e790907021501o9676fe8yc296c62407976d5c@mail.gmail.com> Message-ID: <20090711031032.GA3717@whirlpool.galois.com> gwern0: > OK, let's apply a little democracy here. Reading back through the > thread, I tally the votes: > > # Nothing > David Menendez > John Meachem (?) > > # Just > ## Control.Monad.ignore m a -> m () > Michael Snoyman > Neil Mitchell > Isaac Dupree > Maur??cio > Martijn van Steenbergen > > ### Control.Monad.ignore f a -> f () > Edward Kmett > > ## Control.Monad.void m a -> m () > Don Stewart > Iavor Diatchki That's an odd mix too. I wonder if we even reached quorum. -- Don From roconnor at theorem.ca Fri Jul 10 23:28:31 2009 From: roconnor at theorem.ca (roconnor@theorem.ca) Date: Fri Jul 10 23:10:34 2009 Subject: Adding swap to Data.Tuple In-Reply-To: <7fb8f82f0906172244h32a89d3cpa98a82a35afef4e@mail.gmail.com> References: <404396ef0906160851k62b30e51u1d82a351015af283@mail.gmail.com> <4a393a3b.1818d00a.05f6.0054@mx.google.com> <7fb8f82f0906172224v2fd24f0bqfe2a9323477ece85@mail.gmail.com> <1245302828.3893.1.camel@jonathans-macbook> <7fb8f82f0906172244h32a89d3cpa98a82a35afef4e@mail.gmail.com> Message-ID: Reopening discussion. I believe that swap should be lazy by default in order to be consistent with how uncurry works. -- Russell O'Connor ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' From ashley at semantic.org Sat Jul 11 03:39:53 2009 From: ashley at semantic.org (Ashley Yakeley) Date: Sat Jul 11 03:21:57 2009 Subject: Bug in old-locale? In-Reply-To: <694519c50906281746i7e5d3b10raeecd0980d78e23f@mail.gmail.com> References: <7b501d5c0904200827h35b8b917w19049bfc7c7afaaa@mail.gmail.com> <49EDE6DE.20701@semantic.org> <694519c50906281746i7e5d3b10raeecd0980d78e23f@mail.gmail.com> Message-ID: <1247297993.13958.20.camel@glastonbury> On Sun, 2009-06-28 at 19:46 -0500, Antoine Latter wrote: > old-time handles the padding by eating it. The attached patch does the > same for the time package. > > From reading the date(1) manpage, there are some other parts of the > format-spec not supported. But we at least parse the format-specs we > ship with. I have decided to implement the glibc-specific formatting flags, "_-0^#". Do a "man strftime" on a glibc system to see. I compare with the system strftime as a test (which won't work on a non-glibc system, but I think that's OK). The trouble is that the glibc behaviour of "#" is bizarre. Sometimes it converts to upper case, sometimes it converts to lower case, and sometimes it does nothing. Despite what the man page says, it never "swaps" the case, even for %Z. I am tempted to have "#" always convert to lower case. This is the most predictable and useful behaviour. -- Ashley Yakeley From ashley at semantic.org Sat Jul 11 04:03:36 2009 From: ashley at semantic.org (Ashley Yakeley) Date: Sat Jul 11 03:45:40 2009 Subject: Bug in old-locale? In-Reply-To: <1247297993.13958.20.camel@glastonbury> References: <7b501d5c0904200827h35b8b917w19049bfc7c7afaaa@mail.gmail.com> <49EDE6DE.20701@semantic.org> <694519c50906281746i7e5d3b10raeecd0980d78e23f@mail.gmail.com> <1247297993.13958.20.camel@glastonbury> Message-ID: <4A584758.5070402@semantic.org> I wrote: > I have decided to implement the glibc-specific formatting flags, > "_-0^#". Pushed to repository. -- Ashley Yakeley From ganesh at earth.li Sat Jul 11 14:00:23 2009 From: ganesh at earth.li (Ganesh Sittampalam) Date: Sat Jul 11 13:42:25 2009 Subject: Adding an ignore function to Control.Monad In-Reply-To: References: <4A4C2572.60006@isaac.cedarswampstudios.org> <404396ef0907012326j6ca93absa27d01bcf04eafe1@mail.gmail.com> <7fb8f82f0907020100n4a8bc570q60e9550ec57aef0a@mail.gmail.com> <20090702172217.GE27889@whirlpool.galois.com> <5ab17e790907021501o9676fe8yc296c62407976d5c@mail.gmail.com> Message-ID: On Fri, 10 Jul 2009, Gwern Branwen wrote: > OK, let's apply a little democracy here. Reading back through the > thread, I tally the votes: This shouldn't really be considered a straight vote, but: > ## Control.Monad.ignore m a -> m () > ### Control.Monad.ignore f a -> f () +1 for either of these options. Ganesh From michael at snoyman.com Sat Jul 11 16:03:49 2009 From: michael at snoyman.com (Michael Snoyman) Date: Sat Jul 11 15:45:51 2009 Subject: Adding an ignore function to Control.Monad In-Reply-To: <20090711031032.GA3717@whirlpool.galois.com> References: <4A4C2572.60006@isaac.cedarswampstudios.org> <404396ef0907012326j6ca93absa27d01bcf04eafe1@mail.gmail.com> <7fb8f82f0907020100n4a8bc570q60e9550ec57aef0a@mail.gmail.com> <20090702172217.GE27889@whirlpool.galois.com> <5ab17e790907021501o9676fe8yc296c62407976d5c@mail.gmail.com> <20090711031032.GA3717@whirlpool.galois.com> Message-ID: <29bf512f0907111303o494a8cadgb139b7997de5bd49@mail.gmail.com> I'm not opposed to using void instead of ignore. Out of curiosity, is anyone interested in having the Functor version of void? I'm not sure I see a reason to unnecessarily limit ourselves to Monads here. Also, if we do end up using void, what's going to happen with the FFI copy? Michael On Sat, Jul 11, 2009 at 6:10 AM, Don Stewart wrote: > gwern0: > > OK, let's apply a little democracy here. Reading back through the > > thread, I tally the votes: > > > > # Nothing > > David Menendez > > John Meachem (?) > > > > # Just > > ## Control.Monad.ignore m a -> m () > > Michael Snoyman > > Neil Mitchell > > Isaac Dupree > > Maur??cio > > Martijn van Steenbergen > > > > ### Control.Monad.ignore f a -> f () > > Edward Kmett > > > > ## Control.Monad.void m a -> m () > > Don Stewart > > Iavor Diatchki > > > That's an odd mix too. I wonder if we even reached quorum. > > -- Don > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090711/ffffac7a/attachment-0001.html From igloo at earth.li Sat Jul 11 17:50:56 2009 From: igloo at earth.li (Ian Lynagh) Date: Sat Jul 11 17:32:57 2009 Subject: PROPOSAL: Put DiffArray in its own diffarray package Message-ID: <20090711215056.GA20517@matrix.chaos.earth.li> Hi all, Proposal: Put DiffArray in its own diffarray package http://hackage.haskell.org/trac/ghc/ticket/3370 DiffArray currently has serious performance problems; see http://hackage.haskell.org/trac/ghc/ticket/2727 and is not currently being actively maintained. However, as part of the corelib array it gives the impression that it is a "blessed" library. I propose that we split DiffArray off into its own diffarray package. This also has the advantage that it can then be maintained by a separate maintainer, if someone is interested, and it will be decoupled from GHC's major release schedule. Deadline: 26 July (2 weeks). Thanks Ian From dons at galois.com Sat Jul 11 17:53:35 2009 From: dons at galois.com (Don Stewart) Date: Sat Jul 11 17:37:35 2009 Subject: PROPOSAL: Put DiffArray in its own diffarray package In-Reply-To: <20090711215056.GA20517@matrix.chaos.earth.li> References: <20090711215056.GA20517@matrix.chaos.earth.li> Message-ID: <20090711215335.GA7280@whirlpool.galois.com> igloo: > > Hi all, > > Proposal: > Put DiffArray in its own diffarray package > http://hackage.haskell.org/trac/ghc/ticket/3370 > > DiffArray currently has serious performance problems; see > http://hackage.haskell.org/trac/ghc/ticket/2727 > and is not currently being actively maintained. However, as part of the > corelib array it gives the impression that it is a "blessed" library. > > I propose that we split DiffArray off into its own diffarray package. > This also has the advantage that it can then be maintained by a separate > maintainer, if someone is interested, and it will be decoupled from > GHC's major release schedule. > > Deadline: 26 July (2 weeks). +1 strong in favor. -- Don From gwern0 at gmail.com Sat Jul 11 19:10:11 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Sat Jul 11 18:52:12 2009 Subject: PROPOSAL: Put DiffArray in its own diffarray package In-Reply-To: <20090711215056.GA20517@matrix.chaos.earth.li> References: <20090711215056.GA20517@matrix.chaos.earth.li> Message-ID: On Sat, Jul 11, 2009 at 5:50 PM, Ian Lynagh wrote: > Hi all, > > Proposal: > ? ?Put DiffArray in its own diffarray package > ? ?http://hackage.haskell.org/trac/ghc/ticket/3370 > > DiffArray currently has serious performance problems; see > ? ?http://hackage.haskell.org/trac/ghc/ticket/2727 > and is not currently being actively maintained. However, as part of the > corelib array it gives the impression that it is a "blessed" library. > > I propose that we split DiffArray off into its own diffarray package. > This also has the advantage that it can then be maintained by a separate > maintainer, if someone is interested, and it will be decoupled from > GHC's major release schedule. > > Deadline: 26 July (2 weeks). > > > Thanks > Ian I don't see any packages using DiffArray among the repos I have locally (which I think includes all the major packages), so this sounds good to me too. -- gwern From john at repetae.net Sat Jul 11 23:00:23 2009 From: john at repetae.net (John Meacham) Date: Sat Jul 11 22:42:26 2009 Subject: PROPOSAL: Put DiffArray in its own diffarray package In-Reply-To: <20090711215056.GA20517@matrix.chaos.earth.li> References: <20090711215056.GA20517@matrix.chaos.earth.li> Message-ID: <20090712030022.GO4430@sliver.repetae.net> Speaking of DiffArray, has anyone ever tried their hand at implementing some of the more advanced functional array algorithms for haskell? like the following for instance? http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.55.608 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.8500 they claim some really nice properties, I wonder how well they would work as an implementation for the standard pure arrays in haskell. John -- John Meacham - ?repetae.net?john? - http://notanumber.net/ From nicolas.pouillard at gmail.com Sun Jul 12 05:54:54 2009 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Sun Jul 12 05:38:19 2009 Subject: Adding an ignore function to Control.Monad In-Reply-To: <29bf512f0907111303o494a8cadgb139b7997de5bd49@mail.gmail.com> References: <4A4C2572.60006@isaac.cedarswampstudios.org> <404396ef0907012326j6ca93absa27d01bcf04eafe1@mail.gmail.com> <7fb8f82f0907020100n4a8bc570q60e9550ec57aef0a@mail.gmail.com> <20090702172217.GE27889@whirlpool.galois.com> <5ab17e790907021501o9676fe8yc296c62407976d5c@mail.gmail.com> <20090711031032.GA3717@whirlpool.galois.com> <29bf512f0907111303o494a8cadgb139b7997de5bd49@mail.gmail.com> Message-ID: <1247392338-sup-3371@ausone.home> Excerpts from Michael Snoyman's message of Sat Jul 11 22:03:49 +0200 2009: > I'm not opposed to using void instead of ignore. Out of curiosity, is anyone > interested in having the Functor version of void? I'm not sure I see a > reason to unnecessarily limit ourselves to Monads here. +1 to a functor version Moreover I also think void should be related to an empty type. What about 'discard'? > Also, if we do end up using void, what's going to happen with the FFI copy? > > Michael > > On Sat, Jul 11, 2009 at 6:10 AM, Don Stewart wrote: > > > gwern0: > > > OK, let's apply a little democracy here. Reading back through the > > > thread, I tally the votes: > > > > > > # Nothing > > > David Menendez > > > John Meachem (?) > > > > > > # Just > > > ## Control.Monad.ignore m a -> m () > > > Michael Snoyman > > > Neil Mitchell > > > Isaac Dupree > > > Maur??cio > > > Martijn van Steenbergen > > > > > > ### Control.Monad.ignore f a -> f () > > > Edward Kmett > > > > > > ## Control.Monad.void m a -> m () > > > Don Stewart > > > Iavor Diatchki > > > > > > That's an odd mix too. I wonder if we even reached quorum. -- Nicolas Pouillard http://nicolaspouillard.fr From lemming at henning-thielemann.de Mon Jul 13 16:56:09 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Jul 13 16:37:34 2009 Subject: Adding a newtype EndoCategory to Control.Category (ticket #3362) In-Reply-To: <7fb8f82f0907090617n3d69810au359fba9bd260295f@mail.gmail.com> References: <20090708080255.GB5353@soi.city.ac.uk> <7fb8f82f0907080633r5e1c959co58b4a7f7ac5ec7e@mail.gmail.com> <7fb8f82f0907081215x22b730e0ia2fe672915251003@mail.gmail.com> <20090708233140.GA11227@soi.city.ac.uk> <20090709115615.GA6038@soi.city.ac.uk> <7fb8f82f0907090617n3d69810au359fba9bd260295f@mail.gmail.com> Message-ID: <4A5B9F69.6020700@henning-thielemann.de> Edward Kmett schrieb: > As the devil's advocate I'd like to point out that we could just leave > Endo alone, and define its generalized counterpart separately. No > worries about TypeSynonymInstances and no hassle. +1 I don't see a need to give up Endo as it is. Some of the packages listed by Ross are mine (synthesizer, synthesizer-core, midi, explicit-exception, special-functor (compatibility package for GHC-6.4)). I often use Endo as poor man's diff list implementation. From ashley at semantic.org Tue Jul 14 01:22:14 2009 From: ashley at semantic.org (Ashley Yakeley) Date: Tue Jul 14 01:04:24 2009 Subject: Data.Fixed.Fixed constructor Message-ID: I'm currently working on updating the Data.Fixed module in base. I am adding Typeable and Data instances (automatically derived), and several new HasResolution types (including one for 10^-2, monetary currencies being an obvious Fixed use). The Fixed type is simply a newtype of Integer. Should I expose its MkFixed constructor? Against: * MkFixed is not used in numerical calculation, and isn't itself a conversion function from Integer (obviously). * Ratio doesn't expose its constructor. For: * It's possible to recreate it anyway. * There's a Data instance, so morally the constructor is exposed. -- Ashley Yakeley From marlowsd at gmail.com Tue Jul 14 09:19:35 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Jul 14 09:01:31 2009 Subject: Proposal #3337: expose Unicode and newline translation from System.IO In-Reply-To: <6d74b0d20907021504t166ff564sc148d5eff3d8de90@mail.gmail.com> References: <4A49FF05.3020907@gmail.com> <6d74b0d20907021504t166ff564sc148d5eff3d8de90@mail.gmail.com> Message-ID: <4A5C85E7.5000706@gmail.com> On 02/07/2009 23:04, Judah Jacobson wrote: > 1) It would be good to have an hGetEncoding function, so that we can > temporarily set the encoding of a Handle like stdin without affecting > the rest of the program. I have added this, but it might not behave exactly as you want. hGetEncoding :: Handle -> IO (Maybe TextEncoding) The issue is saving and restoring of the codec state. A TextEncoding is a factory that makes new codec instances; it has no state. However, the codec in use on a Handle does have a state. So if you save and restore the codec, you lose the state. e.g. in UTF-16, you'll get a new BOM in the output. You might or might not want to save and restore the state, I can imagine both possibilities being useful. For now however, I propose we provide the non-state-saving version, clearly documented as such. Providing a state-saving version would need a new type to represent the codec + state, incedentally. > 2) It looks like your API always throws an error on invalid input; it > would be great if there were some way to customize this behavior. > Nothing complicated, maybe just an enum which specifies one of the > following behaviors: > > - throw an error > - ignore (i.e., drop) invalid bytes/Chars > - replace undecodable bytes with u+FFFD and unencodable Chars with '?' > > My preference for the API change would be to add a function in > GHC.IO.Encoding.Iconv; for example, > > mkTextEncodingError :: String -> ErrorHandling -> IO TextEncoding > > since this is similar to how GHC.IO.Encoding.Latin1 allows error > handling by providing latin1 and latin1_checked as separate encoders. > > Any more complicated behavior is probably best handled by something > like the text package. Note that if you're using GNU iconv, you can say mkTextEncoding "UTF-8//IGNORE" to get the version that silently drops illegal characters (there's also "//TRANSLIT", which tries to find an alternative for an illegal character). This is not portable, so I can't provide it as a general facility in GHC.IO.Encoding.Iconv. Cheers, Simon From duncan.coutts at worc.ox.ac.uk Wed Jul 15 03:47:39 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jul 15 03:29:55 2009 Subject: Volunteers for a Haskell Platform steering committee Message-ID: <1247644059.22466.9715.camel@localhost> All, We recently discussed on the libraries list the issue of major vs minor releases, their frequency and what should be included in each. http://trac.haskell.org/haskell-platform/wiki/Policy There are a number of other policy decisions about the Haskell Platform that we will need to make in the coming weeks and months. The platform is supposed to be owned by and serve the interests of the community. As such it is important that significant decisions have some kind of community backing. The intention is that important issues are brought to the libraries mailing list, debated there and decisions reached. To ensure that the relevant issues are indeed discussed and decisions get made, we are proposing a steering committee. It would be the job of the steering committee to see that the important issues are properly discussed and decisions are made and recorded. It would be up to the committee to decide what issues to present, how to start discussions and if necessary how to guide them. Here are some examples of issues that the steering committee will likely want to bring to the attention of this mailing list: * general package quality requirements * portability (OS and compiler/language) * balance of quality vs quantity in libraries * license requirements * procedures for deciding which packages to add (or drop) It is not the intention that the committee members get much more say in policy decisions than other active contributors to discussion on the libraries mailing list. We hope therefore that the membership of the committee does not need to be terribly formal. The only difficulty comes when consensus cannot be reached on an issue where making some decision is widely agreed to be better than making no decision. There is no specified protocol for this situation at this stage. There would obviously have to be good communication between the steering committee and the platform release team. The needs of the release team will inform the issues that get discussed and obviously the libraries list cannot mandate that the release team do the impractical. We are now seeking volunteers for this steering committee. A good number is probably around five. Comments, criticisms and volunteers please! Duncan PS. I'm going to be away 'til Sunday. From ml at isaac.cedarswampstudios.org Wed Jul 15 13:04:06 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Wed Jul 15 12:46:05 2009 Subject: Volunteers for a Haskell Platform steering committee In-Reply-To: <1247644059.22466.9715.camel@localhost> References: <1247644059.22466.9715.camel@localhost> Message-ID: <4A5E0C06.1000309@isaac.cedarswampstudios.org> Duncan Coutts wrote: > We are now seeking volunteers for this steering committee. A good number > is probably around five. > > Comments, criticisms and volunteers please! sounds acceptable. A commitment not to let the issue drop (It seems especially important to create such a commitment to get us through the first year of doing HP). I'll volunteer... -Isaac From johan.tibell at gmail.com Wed Jul 15 13:07:33 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed Jul 15 12:49:44 2009 Subject: Volunteers for a Haskell Platform steering committee In-Reply-To: <4A5E0C06.1000309@isaac.cedarswampstudios.org> References: <1247644059.22466.9715.camel@localhost> <4A5E0C06.1000309@isaac.cedarswampstudios.org> Message-ID: <90889fe70907151007s150a1ea6if68c9e538e0ebead@mail.gmail.com> On Wed, Jul 15, 2009 at 7:04 PM, Isaac Dupree < ml@isaac.cedarswampstudios.org> wrote: > Duncan Coutts wrote: > >> We are now seeking volunteers for this steering committee. A good number >> is probably around five. >> >> Comments, criticisms and volunteers please! >> > > sounds acceptable. A commitment not to let the issue drop (It seems > especially important to create such a commitment to get us through the first > year of doing HP). I'll volunteer... I volunteer too. -- Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090715/baba54e5/attachment.html From tonyhannan2 at gmail.com Thu Jul 16 14:21:55 2009 From: tonyhannan2 at gmail.com (Tony Hannan) Date: Thu Jul 16 14:03:42 2009 Subject: cabal: : openFile: does not exist (No such file or directory) Message-ID: Hello, I'm on Ubuntu 8.10. I installed ghc 6.10.4 (from binary package: ghc-6.10.4-i386-unknown-linux-n.tar.bz2). I installed haskell-platform-2009.2.0.1 (from source package: haskell-platform-2009.2.0.1.tar.gz). It contains cabal-install-0.6.2. Then when I run "cabal update", I get the following error: cabal: : openFile: does not exist (No such file or directory) Any ideas? Thanks, Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090716/7deb63c7/attachment.html From wasserman.louis at gmail.com Thu Jul 16 19:48:33 2009 From: wasserman.louis at gmail.com (Louis Wasserman) Date: Thu Jul 16 19:30:38 2009 Subject: Proposal #3271: new methods for Data.Sequence Message-ID: In response to Ross's useful suggestions (which I had not actually noticed until recently), I have made considerable changes to my Data.Sequence patch here . Here are the relevant points: - I completely rewrote the sorting method. The sort is unstable, but it is 40 lines (much more maintainable than the several-hundred line implementation from earlier) and runs *twice as fast as* (fromList . Data.List.sort . toList) for n=50000. (For sorted lists, it clocks in at about 4x faster.) - tails and inits are considerably more sophisticated, running to about 50 lines apiece (although some of that code is shared between them), but - This implementation is genuinely asymptotically faster than the previous implementation: evaluating any tail from the sequence returned by tails takes O(log (min (i, n-i))), as opposed to O(n) in scanr (<|) empty xs, but evaluating every tail from the sequence takes O(n) overall, as opposed to O(n log n) in fromList [drop n xs | n <- [0..length xs]]. - Without direct access to the internals of the sequence it is impossible to match the asymptotic performance of this implementation. - This implementation is also a hair faster in practice. - partition is now in fact implemented via a simple foldl', which is actually faster than my old, several-dozen-line implementation as well as obviously simpler. - filter has been added to the list of methods available in Data.Sequence. - iterate has been renamed to iterateN to reinforce the different type, which requires a finite bound on the sequence length. - On the back end, replicate, iterateN, and sortBy do not use fromList, but instead use a common framework that wraps construction of a sequence in an Applicative functor. This automatically induces the node sharing that gives replicate performance O(log n), but behaves exactly correctly for all its other requirements. - As a result, there is a faster alternative to fromList if the length of the list is known. The name and type of this method seems like it might become genuinely contentious, so I'm not inclined to expose that faster method at the moment. Louis Wasserman wasserman.louis@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090716/4c59c67a/attachment.html From john at repetae.net Thu Jul 16 19:53:19 2009 From: john at repetae.net (John Meacham) Date: Thu Jul 16 19:35:06 2009 Subject: Proposal #3271: new methods for Data.Sequence In-Reply-To: References: Message-ID: <20090716235319.GA21698@sliver.repetae.net> On Thu, Jul 16, 2009 at 07:48:33PM -0400, Louis Wasserman wrote: > - I completely rewrote the sorting method. The sort is unstable, but it > is 40 lines (much more maintainable than the several-hundred line > implementation from earlier) and runs *twice as fast as* (fromList . > Data.List.sort . toList) for n=50000. (For sorted lists, it clocks in at > about 4x faster.) I think a stable sort is pretty much essential. Can you modify your better sorting algorithm to be stable? What algorithm is it BTW? John -- John Meacham - ?repetae.net?john? - http://notanumber.net/ From g9ks157k at acme.softbase.org Fri Jul 17 09:43:08 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Fri Jul 17 09:24:56 2009 Subject: Adding an ignore function to Control.Monad In-Reply-To: <1247392338-sup-3371@ausone.home> References: <29bf512f0907111303o494a8cadgb139b7997de5bd49@mail.gmail.com> <1247392338-sup-3371@ausone.home> Message-ID: <200907171543.08914.g9ks157k@acme.softbase.org> Am Sonntag, 12. Juli 2009 11:54 schrieb Nicolas Pouillard: > Excerpts from Michael Snoyman's message of Sat Jul 11 22:03:49 +0200 2009: > > I'm not opposed to using void instead of ignore. Out of curiosity, is > > anyone interested in having the Functor version of void? I'm not sure I > > see a reason to unnecessarily limit ourselves to Monads here. > > +1 to a functor version +1 The function could be used, for example, as a parser, and parsers are not always monads. > What about 'discard'? Sounds good. Best wishes, Wolfgang From g9ks157k at acme.softbase.org Fri Jul 17 09:56:13 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Fri Jul 17 09:38:01 2009 Subject: proposal #3335: make some Applicative functions into methods, and split off Data.Functor In-Reply-To: <49a77b7a0906291501y1e87c7bdy9b03542b0db15b4c@mail.gmail.com> References: <20090629124545.GA6378@soi.city.ac.uk> <20090629203143.GA10014@soi.city.ac.uk> <49a77b7a0906291501y1e87c7bdy9b03542b0db15b4c@mail.gmail.com> Message-ID: <200907171556.13182.g9ks157k@acme.softbase.org> Am Dienstag, 30. Juni 2009 00:01 schrieb David Menendez: > On Mon, Jun 29, 2009 at 4:31 PM, Ross Paterson wrote: > > On Mon, Jun 29, 2009 at 02:37:56PM -0400, David Menendez wrote: > >> How about liftA2? > > > > 2 is a scary number. ?Do you have an example in mind where a customized > > liftA2 would be a big win? > > I don't know about a big win, but my preference for Applicative has > always been to define <*> and liftA2 as co-primitives, like so: > > class Functor f => Applicative f where > pure :: a -> f a > liftA2 :: (a -> b -> c) -> f a -> f b -> f c > (<*>) :: f (a -> b) -> f a -> f b > > (<*>) = liftA2 ($) > liftA2 f a b = fmap f a <*> b Wouldn?t it make more sense to define (<*>) and pair as co-primitives, where pair = liftA2 (,)? class Functor f => Applicative f where pure :: a -> f a pair :: f a -> f b -> f (a,b) (<*>) :: f (a -> b) -> f a -> f b (<*>) = fmap (uncurry ($)) . pair pair fa fb = pure (,) <*> fa <*> fb Best wishes, Wolfgang From g9ks157k at acme.softbase.org Fri Jul 17 10:03:25 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Fri Jul 17 09:45:12 2009 Subject: Proposal #3339: Add (+>) as a synonym for mappend In-Reply-To: <7fb8f82f0907010759v56d5456cy679333d414aa3888@mail.gmail.com> References: <7fb8f82f0907010759v56d5456cy679333d414aa3888@mail.gmail.com> Message-ID: <200907171603.25456.g9ks157k@acme.softbase.org> Am Mittwoch, 1. Juli 2009 16:59 schrieb Edward Kmett: > Bikeshedding: Would it be better to put the definition for +> (or better > yet <>) in the dictionary for Monoid with a circular definition for > mappend? That way new code defining Monoid instances can avoid ever having > to even mention mappend. +1 Best wishes, Wolfgang From dave at zednenem.com Fri Jul 17 10:38:10 2009 From: dave at zednenem.com (David Menendez) Date: Fri Jul 17 10:19:54 2009 Subject: proposal #3335: make some Applicative functions into methods, and split off Data.Functor In-Reply-To: <200907171556.13182.g9ks157k@acme.softbase.org> References: <20090629124545.GA6378@soi.city.ac.uk> <20090629203143.GA10014@soi.city.ac.uk> <49a77b7a0906291501y1e87c7bdy9b03542b0db15b4c@mail.gmail.com> <200907171556.13182.g9ks157k@acme.softbase.org> Message-ID: <49a77b7a0907170738y1b3d7b17hc04e73f9e34f4e83@mail.gmail.com> On Fri, Jul 17, 2009 at 9:56 AM, Wolfgang Jeltsch wrote: > Am Dienstag, 30. Juni 2009 00:01 schrieb David Menendez: >> On Mon, Jun 29, 2009 at 4:31 PM, Ross Paterson wrote: >> > On Mon, Jun 29, 2009 at 02:37:56PM -0400, David Menendez wrote: >> >> How about liftA2? >> > >> > 2 is a scary number. ?Do you have an example in mind where a customized >> > liftA2 would be a big win? >> >> I don't know about a big win, but my preference for Applicative has >> always been to define <*> and liftA2 as co-primitives, like so: >> >> class Functor f => Applicative f where >> ? ? pure :: a -> f a >> ? ? liftA2 :: (a -> b -> c) -> f a -> f b -> f c >> ? ? (<*>) :: f (a -> b) -> f a -> f b >> >> ? ? (<*>) = liftA2 ($) >> ? ? liftA2 f a b = fmap f a <*> b > > Wouldn?t it make more sense to define (<*>) and pair as co-primitives, where > pair = liftA2 (,)? Defining pair in terms of liftA2 is simpler than defining liftA2 in terms of pair. pair = liftA2 (,) -- just partial application liftA2 f a b =uncurry f <$> pair a b -- creates and destroys an intermediate representation -- Dave Menendez From alexander.dunlap at gmail.com Fri Jul 17 10:53:23 2009 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Fri Jul 17 10:35:28 2009 Subject: Proposal #3339: Add (+>) as a synonym for mappend In-Reply-To: References: Message-ID: <57526e770907170753m69943014m772decbb46c8ce4d@mail.gmail.com> On Tue, Jun 30, 2009 at 5:37 PM, Bryan O'Sullivan wrote: > Ticket: http://hackage.haskell.org/trac/ghc/ticket/3339 > > From the ticket: > > This proposal was, I think, originally suggested by Jules Bean. The idea is > to add two functions to the Data.Monoid module, (+>) and (<+), corresponding > to different uses of mappend. These should not be methods of the Monoid > typeclass, but top-level functions. > > I hope (but slightly doubt) that the visual nature of the two operators > might help to counter the thought that monoids are just for gluing things > together. > > (+>) :: (Monoid a) => a -> a -> a > a +> b = a `mappend` b > > (<+) :: (Monoid a) => a -> a -> a > a <+ b = b `mappend` a > > infixl 4 +> > infixl 4 <+ > > Proposed deadline: two weeks. > > If this looks reasonable, I'll attach darcs patches. > I (and apparently a lot of other people who commented on that ticket) would prefer that (++) be generalized instead of introducing a new operator. Alex From tphyahoo at gmail.com Fri Jul 17 11:17:07 2009 From: tphyahoo at gmail.com (Thomas Hartman) Date: Fri Jul 17 10:58:50 2009 Subject: cabal: : openFile: does not exist (No such file or directory) In-Reply-To: References: Message-ID: <910ddf450907170817l108bacc6m6563eb49e02b3636@mail.gmail.com> cabal -v3 update will give you a more verbose version of what is going wrong. cabal --help regrettably, cabal --help doesn't tell you this but there is always the man page I suppose. 2009/7/16 Tony Hannan : > Hello, > > I'm on Ubuntu 8.10. > I installed ghc 6.10.4 (from binary package: > ghc-6.10.4-i386-unknown-linux-n.tar.bz2). > I installed haskell-platform-2009.2.0.1 (from source package: > haskell-platform-2009.2.0.1.tar.gz). It contains cabal-install-0.6.2. > > Then when I run "cabal update", I get the following error: > cabal:? : openFile: does not exist (No such file or directory) > > Any ideas? > > Thanks, > Tony > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > From igloo at earth.li Fri Jul 17 11:33:24 2009 From: igloo at earth.li (Ian Lynagh) Date: Fri Jul 17 11:15:09 2009 Subject: random tune In-Reply-To: <431fb4c10907090242s3307445ci2548bca2e66b3fc0@mail.gmail.com> References: <431fb4c10907090242s3307445ci2548bca2e66b3fc0@mail.gmail.com> Message-ID: <20090717153324.GA25885@matrix.chaos.earth.li> On Thu, Jul 09, 2009 at 11:42:20AM +0200, Laszlo Nagy wrote: > > I also run the hlint program > against the random library and applied the recommendations. Here are > the patches: > > http://sites.google.com/site/rizsotto/patches/random-hlintclean.darcs Thanks for taking the time to look into this. I'd be interested in other people's opinions on whether the hlint recommendations are an improvement or not. In my opinion there are a handful of things that are slightly less clear for no real benefit: createStdGen :: Integer -> StdGen -createStdGen s = mkStdGen32 $ fromIntegral s +createStdGen = mkStdGen32 . fromIntegral randoms :: RandomGen g => g -> [a] - randoms g = (\(x,g') -> x : randoms g') (random g) + randoms = (\(x,g') -> x : randoms g') . random theStdGen :: IORef StdGen -theStdGen = unsafePerformIO $ do - rng <- mkStdRNG 0 - newIORef rng +theStdGen = unsafePerformIO $ mkStdRNG 0 >>= newIORef In fact, I would change randoms to: randoms g = case random g of (x,g') -> x : randoms g' And the rest aren't really better or worse in my opinion, e.g.: instance Random Int where - randomR (a,b) g = randomIvalInteger (toInteger a, toInteger b) g - random g = randomR (minBound,maxBound) g + randomR (a,b) = randomIvalInteger (toInteger a, toInteger b) + random = randomR (minBound,maxBound) > http://sites.google.com/site/rizsotto/patches/random-time.darcs Thanks; I'll take a look at adding time to GHC's corelibs, and then apply this. Thanks Ian From wasserman.louis at gmail.com Fri Jul 17 12:29:23 2009 From: wasserman.louis at gmail.com (Louis Wasserman) Date: Fri Jul 17 12:11:26 2009 Subject: Proposal #3271: new methods for Data.Sequence Message-ID: The faster sort for Data.Sequence is a heapsort based on a pairing heap implementation. The only way I can think of to make it stable is to index the entire sequence and then add indices to the comparisons, which removes almost all of the benefit of the heapsort implementation: Times (ms) min mean +/-sd median max to/from list: 106.742 111.269 4.831 110.207 138.638 pairing heap: 62.896 66.066 2.410 65.433 74.471 stable pheap: 95.600 102.381 5.807 100.744 120.395 Even worse, the stable heapsort becomes genuinely worse when there's memory to spare; with +RTS -H128m: Times (ms) min mean +/-sd median max to/from list: 53.675 84.407 14.130 86.319 108.553 pairing heap: 62.492 77.065 9.649 78.883 104.606 stable pheap: 70.437 97.718 15.332 100.548 134.624 Perhaps the most reasonable compromise would be to include the faster sort method, but name it sortBy' or something else indicating that it is nonstandard. (That still leaves open the question of whether the stable sort method should be the Data.List conversion, or the stable heapsort.) I had forgotten to mention that zipWith had been modified to a one-liner with mapAccumL, which actually proved faster than my implementation. Louis Wasserman wasserman.louis@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090717/dcad529c/attachment.html From clifford.beshers at gmail.com Fri Jul 17 12:53:08 2009 From: clifford.beshers at gmail.com (Clifford Beshers) Date: Fri Jul 17 12:34:51 2009 Subject: random tune In-Reply-To: <20090717153324.GA25885@matrix.chaos.earth.li> References: <431fb4c10907090242s3307445ci2548bca2e66b3fc0@mail.gmail.com> <20090717153324.GA25885@matrix.chaos.earth.li> Message-ID: <6841b9520907170953x7ce0398cgeee47d987e7b2650@mail.gmail.com> Ian, I don't think it matters much either way. Personally, I like the point-free style. Of all the things that have puzzled me over the years when reading core libraries, that was one of the easiest to learn about. One can hardly miss it if one visits #haskell at all. On Fri, Jul 17, 2009 at 8:33 AM, Ian Lynagh wrote: > On Thu, Jul 09, 2009 at 11:42:20AM +0200, Laszlo Nagy wrote: > > > > I also run the hlint program > > against the random library and applied the recommendations. Here are > > the patches: > > > > http://sites.google.com/site/rizsotto/patches/random-hlintclean.darcs > > Thanks for taking the time to look into this. > > I'd be interested in other people's opinions on whether the hlint > recommendations are an improvement or not. > > In my opinion there are a handful of things that are slightly less clear > for no real benefit: > > createStdGen :: Integer -> StdGen > -createStdGen s = mkStdGen32 $ fromIntegral s > +createStdGen = mkStdGen32 . fromIntegral > > randoms :: RandomGen g => g -> [a] > - randoms g = (\(x,g') -> x : randoms g') (random g) > + randoms = (\(x,g') -> x : randoms g') . random > > theStdGen :: IORef StdGen > -theStdGen = unsafePerformIO $ do > - rng <- mkStdRNG 0 > - newIORef rng > +theStdGen = unsafePerformIO $ mkStdRNG 0 >>= newIORef > > In fact, I would change randoms to: > > randoms g = case random g of > (x,g') -> x : randoms g' > > And the rest aren't really better or worse in my opinion, e.g.: > > instance Random Int where > - randomR (a,b) g = randomIvalInteger (toInteger a, toInteger b) g > - random g = randomR (minBound,maxBound) g > + randomR (a,b) = randomIvalInteger (toInteger a, toInteger b) > + random = randomR (minBound,maxBound) > > > http://sites.google.com/site/rizsotto/patches/random-time.darcs > > Thanks; I'll take a look at adding time to GHC's corelibs, and then > apply this. > > > Thanks > Ian > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090717/82413ba9/attachment.html From ekmett at gmail.com Fri Jul 17 15:57:06 2009 From: ekmett at gmail.com (Edward Kmett) Date: Fri Jul 17 15:38:49 2009 Subject: Proposal #3339: Add (+>) as a synonym for mappend In-Reply-To: <57526e770907170753m69943014m772decbb46c8ce4d@mail.gmail.com> References: <57526e770907170753m69943014m772decbb46c8ce4d@mail.gmail.com> Message-ID: <7fb8f82f0907171257s10444eaakece34caebd55f6ab@mail.gmail.com> The main concern with generalizing (++) is that it was once generalized -- completely differently! -- for mplus in MonadPlus. So whether Monoid's mappend is the natural generalization of (++) or MonadPlus's mplus is, is not entirely clear. Neither one can completely subsume all of the use-cases of the other. A secondary concern is that neither MonadPlus nor Monoid are in the Prelude, so its generalized form would have to be exported from Data.Monoid with a different type signature breaking any pre-existing code that brought in Data.Monoid unqualified and happened to use lists. I'm less sold by the second concern than the first one, but both make me hesitate. Bryan's/Jules's existing proposal of a new operator avoids both of these snarls. -Edward Kmett On Fri, Jul 17, 2009 at 10:53 AM, Alexander Dunlap < alexander.dunlap@gmail.com> wrote: > On Tue, Jun 30, 2009 at 5:37 PM, Bryan O'Sullivan > wrote: > > Ticket: http://hackage.haskell.org/trac/ghc/ticket/3339 > > > > From the ticket: > > > > This proposal was, I think, originally suggested by Jules Bean. The idea > is > > to add two functions to the Data.Monoid module, (+>) and (<+), > corresponding > > to different uses of mappend. These should not be methods of the Monoid > > typeclass, but top-level functions. > > > > I hope (but slightly doubt) that the visual nature of the two operators > > might help to counter the thought that monoids are just for gluing things > > together. > > > > (+>) :: (Monoid a) => a -> a -> a > > a +> b = a `mappend` b > > > > (<+) :: (Monoid a) => a -> a -> a > > a <+ b = b `mappend` a > > > > infixl 4 +> > > infixl 4 <+ > > > > Proposed deadline: two weeks. > > > > If this looks reasonable, I'll attach darcs patches. > > > > I (and apparently a lot of other people who commented on that ticket) > would prefer that (++) be generalized instead of introducing a new > operator. > > Alex > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090717/b80a6980/attachment.html From g9ks157k at acme.softbase.org Sat Jul 18 05:21:10 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Sat Jul 18 05:02:55 2009 Subject: Proposal #3339: Add (+>) as a synonym for mappend In-Reply-To: <7fb8f82f0907171257s10444eaakece34caebd55f6ab@mail.gmail.com> References: <57526e770907170753m69943014m772decbb46c8ce4d@mail.gmail.com> <7fb8f82f0907171257s10444eaakece34caebd55f6ab@mail.gmail.com> Message-ID: <200907181121.10632.g9ks157k@acme.softbase.org> Am Freitag, 17. Juli 2009 21:57 schrieb Edward Kmett: > The main concern with generalizing (++) is that it was once generalized > -- completely differently! -- for mplus in MonadPlus. So whether Monoid's > mappend is the natural generalization of (++) or MonadPlus's mplus is, is > not entirely clear. Neither one can completely subsume all of the use-cases > of the other. I hope that in the long run, we will be able to drop Alternative and MonadPlus. This will be possible once we allow universal quantification in contexts. Instead of writing (MonadPlus m), we can write (Monad m, forall a. Monoid (m a)) then. This makes it rather clear that Monoid (mappend) would be the better generalization of (++). MonadPlus (mplus) is a bit of a hack. Best wishes, Wolfgang From conor at strictlypositive.org Sat Jul 18 06:14:12 2009 From: conor at strictlypositive.org (Conor McBride) Date: Sat Jul 18 05:55:54 2009 Subject: Proposal #3339: Add (+>) as a synonym for mappend In-Reply-To: <200907181121.10632.g9ks157k@acme.softbase.org> References: <57526e770907170753m69943014m772decbb46c8ce4d@mail.gmail.com> <7fb8f82f0907171257s10444eaakece34caebd55f6ab@mail.gmail.com> <200907181121.10632.g9ks157k@acme.softbase.org> Message-ID: <096A8EAC-B172-4934-A278-5D758BEEFA9F@strictlypositive.org> On 18 Jul 2009, at 10:21, Wolfgang Jeltsch wrote: > Am Freitag, 17. Juli 2009 21:57 schrieb Edward Kmett: >> The main concern with generalizing (++) is that it was once >> generalized >> -- completely differently! -- for mplus in MonadPlus. So whether >> Monoid's >> mappend is the natural generalization of (++) or MonadPlus's mplus >> is, is >> not entirely clear. Neither one can completely subsume all of the >> use-cases >> of the other. > > I hope that in the long run, we will be able to drop Alternative and > MonadPlus. This will be possible once we allow universal > quantification in > contexts. Instead of writing (MonadPlus m), we can write (Monad m, > forall a. > Monoid (m a)) then. This makes it rather clear that Monoid (mappend) > would be > the better generalization of (++). MonadPlus (mplus) is a bit of a > hack. Until that joyous day, I'd like to hope we might consider ensuring that MonadPlus m, Alternative m, and Monoid (m a) functionalities do at least coincide. I'm thinking in particular of Maybe, which behaves splendidly as an implementation of an exception monad, until you start using foldMap as a control operator. Cheers Conor From igloo at earth.li Sat Jul 18 08:51:13 2009 From: igloo at earth.li (Ian Lynagh) Date: Sat Jul 18 08:32:53 2009 Subject: PROPOSAL: Remove Control.OldException Message-ID: <20090718125113.GA21683@matrix.chaos.earth.li> Hi all, Proposal: Remove Control.OldException http://hackage.haskell.org/trac/ghc/ticket/3381 We included Control.OldException in base to help people trying to remain compatible with both GHC 6.8 and GHC 6.10. However, my impression is that most (all?) people who wanted compatibility used the extensible-exceptions package instead. I propose that we remove Control.OldException for GHC 6.12. If anyone does want Control.OldException, then it could be provided by a separate package. Deadline: 2nd August (2 weeks). Thanks Ian From ekmett at gmail.com Sat Jul 18 09:23:53 2009 From: ekmett at gmail.com (Edward Kmett) Date: Sat Jul 18 09:05:33 2009 Subject: Proposal #3339: Add (+>) as a synonym for mappend In-Reply-To: <096A8EAC-B172-4934-A278-5D758BEEFA9F@strictlypositive.org> References: <57526e770907170753m69943014m772decbb46c8ce4d@mail.gmail.com> <7fb8f82f0907171257s10444eaakece34caebd55f6ab@mail.gmail.com> <200907181121.10632.g9ks157k@acme.softbase.org> <096A8EAC-B172-4934-A278-5D758BEEFA9F@strictlypositive.org> Message-ID: <7fb8f82f0907180623m7d8ee454g304a8e274a44fa13@mail.gmail.com> On Sat, Jul 18, 2009 at 6:14 AM, Conor McBride wrote: > Until that joyous day, I'd like to hope we might consider ensuring > that MonadPlus m, Alternative m, and Monoid (m a) functionalities > do at least coincide. > > I'm thinking in particular of Maybe, which behaves splendidly as > an implementation of an exception monad, until you start using > foldMap as a control operator. > Yeah, the Monoid instance for Maybe is somewhat unfortunate. I can see where they were going as Maybe does provide the natural extension of a semigroup into a monoid by adding a unit element, but it doesn't have a Semigroup class to build on, and so has to require Monoid and in the end you get a definition that conflicts with the MonadPlus/Alternative instances for Maybe, and only really helps if you have broken Monoid instances around that are secretly just Semigroups. -Edward Kmett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090718/a7995355/attachment.html From conor at strictlypositive.org Sat Jul 18 10:17:00 2009 From: conor at strictlypositive.org (Conor McBride) Date: Sat Jul 18 09:58:43 2009 Subject: Proposal #3339: Add (+>) as a synonym for mappend In-Reply-To: <7fb8f82f0907180623m7d8ee454g304a8e274a44fa13@mail.gmail.com> References: <57526e770907170753m69943014m772decbb46c8ce4d@mail.gmail.com> <7fb8f82f0907171257s10444eaakece34caebd55f6ab@mail.gmail.com> <200907181121.10632.g9ks157k@acme.softbase.org> <096A8EAC-B172-4934-A278-5D758BEEFA9F@strictlypositive.org> <7fb8f82f0907180623m7d8ee454g304a8e274a44fa13@mail.gmail.com> Message-ID: Hi Edward On 18 Jul 2009, at 14:23, Edward Kmett wrote: > > Yeah, the Monoid instance for Maybe is somewhat unfortunate. > > I can see where they were going as Maybe does provide the natural > extension of a semigroup into a monoid by adding a unit element, but > it doesn't have a Semigroup class to build on, and so has to require > Monoid and in the end you get a definition that conflicts with the > MonadPlus/Alternative instances for Maybe, and only really helps if > you have broken Monoid instances around that are secretly just > Semigroups. Exactly. Types should mean more than mere data representations. The current Monoid instance is inconsistent with the broad interpretation of Maybe as a monad for exceptional computations. An isomorphic data representation can and should be used to attach a unit element to a semigroup, Data structures are data with structure. All the best Conor From dons at galois.com Sat Jul 18 12:51:04 2009 From: dons at galois.com (Don Stewart) Date: Sat Jul 18 12:34:45 2009 Subject: PROPOSAL: Remove Control.OldException In-Reply-To: <20090718125113.GA21683@matrix.chaos.earth.li> References: <20090718125113.GA21683@matrix.chaos.earth.li> Message-ID: <20090718165104.GA6997@whirlpool.galois.com> igloo: > > Hi all, > > Proposal: > Remove Control.OldException > http://hackage.haskell.org/trac/ghc/ticket/3381 > > We included Control.OldException in base to help people trying to remain > compatible with both GHC 6.8 and GHC 6.10. However, my impression is > that most (all?) people who wanted compatibility used the > extensible-exceptions package instead. > I'd be very wary of this so early. Try building hackage and tell us what breaks when there is no OldException. -- Don From igloo at earth.li Sat Jul 18 15:22:28 2009 From: igloo at earth.li (Ian Lynagh) Date: Sat Jul 18 15:04:09 2009 Subject: random tune In-Reply-To: <20090717153324.GA25885@matrix.chaos.earth.li> References: <431fb4c10907090242s3307445ci2548bca2e66b3fc0@mail.gmail.com> <20090717153324.GA25885@matrix.chaos.earth.li> Message-ID: <20090718192228.GA14279@matrix.chaos.earth.li> On Fri, Jul 17, 2009 at 04:33:24PM +0100, Ian Lynagh wrote: > On Thu, Jul 09, 2009 at 11:42:20AM +0200, Laszlo Nagy wrote: > > > > http://sites.google.com/site/rizsotto/patches/random-time.darcs > > Thanks; I'll take a look at adding time to GHC's corelibs, and then > apply this. Now applied; thanks for the patch! Thanks Ian From ross at soi.city.ac.uk Sat Jul 18 20:30:13 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sat Jul 18 20:11:54 2009 Subject: Proposal #3271: new methods for Data.Sequence In-Reply-To: References: Message-ID: <20090719003013.GA13356@soi.city.ac.uk> On Thu, Jul 16, 2009 at 07:48:33PM -0400, Louis Wasserman wrote: > * I completely rewrote the sorting method. The sort is unstable, > but it is 40 lines (much more maintainable than the several-hundred > line implementation from earlier) and runs *twice as fast as* > (fromList . Data.List.sort . toList) for n=50000. (For sorted > lists, it clocks in at about 4x faster.) How does it compare against sortBy cmp xs = fromList2 (size xs) (Data.List.sortBy cmp (toList xs)) I'm inclined to agree with John that stability is important in a general purpose sort. > * partition is now in fact implemented via a simple foldl', which > is actually faster than my old, several-dozen-line implementation > as well as obviously simpler. > > I had forgotten to mention that zipWith had been modified to a one-liner > with mapAccumL, which actually proved faster than my implementation. That is good news indeed. From wasserman.louis at gmail.com Sun Jul 19 12:12:49 2009 From: wasserman.louis at gmail.com (Louis Wasserman) Date: Sun Jul 19 11:54:46 2009 Subject: Proposal #3271: new methods for Data.Sequence Message-ID: Ross, fromList2 takes perhaps 3ms off the time when n=50000. (It is essentially a two-liner, so I consider this acceptable.) Nevertheless, I have slightly improved the performance of the stable heapsort; essentially, when labeling values with their index, the index is left as a lazy thunk, but the computation is organized so computing any index takes O(log n). The speed increase from fromList . Data.List.sort . toList is still but 40% of the speed increase from the heapsort. Again, I'd like to propose a compromise: make Data.Sequence.sortBy cmp be either fromList2 . Data.List.sortBy cmp . toList, or use the stable pairing-heap sort, and add a second sorting method, sortBy', that is unstable but faster. Times (ms) min mean +/-sd median max to/from list: 113.561 119.800 5.470 118.678 139.390 pairing heap: 62.440 67.032 3.861 65.174 80.499 stable pheap: 93.402 102.253 11.854 98.529 158.922 fromList2 . toList: 110.221 118.364 6.525 116.265 136.683 Louis Wasserman wasserman.louis@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090719/32b21309/attachment.html From igloo at earth.li Sun Jul 19 13:29:30 2009 From: igloo at earth.li (Ian Lynagh) Date: Sun Jul 19 13:11:07 2009 Subject: PROPOSAL: Remove Control.OldException In-Reply-To: <20090718165104.GA6997@whirlpool.galois.com> References: <20090718125113.GA21683@matrix.chaos.earth.li> <20090718165104.GA6997@whirlpool.galois.com> Message-ID: <20090719172930.GA619@matrix.chaos.earth.li> On Sat, Jul 18, 2009 at 09:51:04AM -0700, Donald Bruce Stewart wrote: > igloo: > > > > Hi all, > > > > Proposal: > > Remove Control.OldException > > http://hackage.haskell.org/trac/ghc/ticket/3381 > > > > We included Control.OldException in base to help people trying to remain > > compatible with both GHC 6.8 and GHC 6.10. However, my impression is > > that most (all?) people who wanted compatibility used the > > extensible-exceptions package instead. > > > > I'd be very wary of this so early. Try building hackage and tell us what > breaks when there is no OldException. I don't have a reasonable way to do an all-of-hackage build at the moment, but I've unpacked the latest version of each package and grepped for "Control.OldException". Of the 1425 packages, 19 mention it: Agda-2.2.4 binary-0.5.0.1 cabalgraph-0.1 chp-1.2.0 darcs-2.2.1 darcs-beta-2.2.98.4 debian-3.35 haddock-2.4.2 HAppS-Server-0.9.3.1 haskeem-0.7.7 HPDF-1.4.2 hsql-postgresql-1.7.3 leksah-0.4.4.1 lscabal-0.1 MissingPy-0.10.3 mueval-0.7.1 plugins-1.4.1 yi-0.6.1 yjftp-0.3.6.2 Thanks Ian From dons at galois.com Sun Jul 19 14:56:30 2009 From: dons at galois.com (Don Stewart) Date: Sun Jul 19 14:40:09 2009 Subject: PROPOSAL: Remove Control.OldException In-Reply-To: <20090719172930.GA619@matrix.chaos.earth.li> References: <20090718125113.GA21683@matrix.chaos.earth.li> <20090718165104.GA6997@whirlpool.galois.com> <20090719172930.GA619@matrix.chaos.earth.li> Message-ID: <20090719185630.GA11801@whirlpool.galois.com> igloo: > On Sat, Jul 18, 2009 at 09:51:04AM -0700, Donald Bruce Stewart wrote: > > igloo: > > > > > > Hi all, > > > > > > Proposal: > > > Remove Control.OldException > > > http://hackage.haskell.org/trac/ghc/ticket/3381 > > > > > > We included Control.OldException in base to help people trying to remain > > > compatible with both GHC 6.8 and GHC 6.10. However, my impression is > > > that most (all?) people who wanted compatibility used the > > > extensible-exceptions package instead. > > > > > > > I'd be very wary of this so early. Try building hackage and tell us what > > breaks when there is no OldException. > > I don't have a reasonable way to do an all-of-hackage build at the > moment, but I've unpacked the latest version of each package and grepped > for "Control.OldException". Of the 1425 packages, 19 mention it: > Oh, I wonder how many are building with base 3 too. Hmm... we should check that. -- Don From nominolo at googlemail.com Sun Jul 19 19:01:35 2009 From: nominolo at googlemail.com (Thomas Schilling) Date: Sun Jul 19 18:43:12 2009 Subject: Volunteers for a Haskell Platform steering committee In-Reply-To: <916b84820907191600n4920c94crb17776eef6ab858@mail.gmail.com> References: <1247644059.22466.9715.camel@localhost> <4A5E0C06.1000309@isaac.cedarswampstudios.org> <90889fe70907151007s150a1ea6if68c9e538e0ebead@mail.gmail.com> <916b84820907191600n4920c94crb17776eef6ab858@mail.gmail.com> Message-ID: <916b84820907191601p1e66bab2h7c7b08c9e4de3fc8@mail.gmail.com> Wrong reply button. ---------- Forwarded message ---------- From: Thomas Schilling Date: 2009/7/20 Subject: Re: Volunteers for a Haskell Platform steering committee To: Johan Tibell Ah, why not. Consider my hand voluntarily raised. 2009/7/15 Johan Tibell : > On Wed, Jul 15, 2009 at 7:04 PM, Isaac Dupree > wrote: >> >> Duncan Coutts wrote: >>> >>> We are now seeking volunteers for this steering committee. A good number >>> is probably around five. >>> >>> Comments, criticisms and volunteers please! >> >> sounds acceptable. ?A commitment not to let the issue drop (It seems >> especially important to create such a commitment to get us through the first >> year of doing HP). ?I'll volunteer... > > I volunteer too. > > -- Johan > > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -- Push the envelope. ?Watch it bend. -- Push the envelope. Watch it bend. From qdunkan at gmail.com Sun Jul 19 21:57:02 2009 From: qdunkan at gmail.com (Evan Laforge) Date: Sun Jul 19 21:38:39 2009 Subject: Proposal #3271: new methods for Data.Sequence In-Reply-To: References: Message-ID: <2518b95d0907191857q29a442b1l86609db8e3e58d17@mail.gmail.com> > Again, I'd like to propose a compromise: make Data.Sequence.sortBy cmp be > either fromList2 . Data.List.sortBy cmp . toList, or use the stable > pairing-heap sort, and add a second sorting method, sortBy', that is > unstable but faster. Sounds good to me but how about calling them unstableSortBy and unstableSort? From iavor.diatchki at gmail.com Mon Jul 20 02:27:43 2009 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon Jul 20 02:09:18 2009 Subject: PROPOSAL: Remove Control.OldException In-Reply-To: <20090719185630.GA11801@whirlpool.galois.com> References: <20090718125113.GA21683@matrix.chaos.earth.li> <20090718165104.GA6997@whirlpool.galois.com> <20090719172930.GA619@matrix.chaos.earth.li> <20090719185630.GA11801@whirlpool.galois.com> Message-ID: <5ab17e790907192327m504521b5h5b0c72ee303036d4@mail.gmail.com> Hello, Please do not remove OldException. -Iavor On Sun, Jul 19, 2009 at 9:56 PM, Don Stewart wrote: > igloo: >> On Sat, Jul 18, 2009 at 09:51:04AM -0700, Donald Bruce Stewart wrote: >> > igloo: >> > > >> > > Hi all, >> > > >> > > Proposal: >> > > ? ? Remove Control.OldException >> > > ? ? http://hackage.haskell.org/trac/ghc/ticket/3381 >> > > >> > > We included Control.OldException in base to help people trying to remain >> > > compatible with both GHC 6.8 and GHC 6.10. However, my impression is >> > > that most (all?) people who wanted compatibility used the >> > > extensible-exceptions package instead. >> > > >> > >> > I'd be very wary of this so early. Try building hackage and tell us what >> > breaks when there is no OldException. >> >> I don't have a reasonable way to do an all-of-hackage build at the >> moment, but I've unpacked the latest version of each package and grepped >> for "Control.OldException". Of the 1425 packages, 19 mention it: >> > > Oh, I wonder how many are building with base 3 too. Hmm... we should > check that. > > -- Don > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From iavor.diatchki at gmail.com Mon Jul 20 02:40:47 2009 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon Jul 20 02:22:22 2009 Subject: Volunteers for a Haskell Platform steering committee In-Reply-To: <1247644059.22466.9715.camel@localhost> References: <1247644059.22466.9715.camel@localhost> Message-ID: <5ab17e790907192340k47ea0102ld33d1a4181aecede@mail.gmail.com> Hi, I feel that I should volunteer too (instead of complaining to Don :-) ) -Iavor On Wed, Jul 15, 2009 at 10:47 AM, Duncan Coutts wrote: > All, > > We recently discussed on the libraries list the issue of major vs minor > releases, their frequency and what should be included in each. > http://trac.haskell.org/haskell-platform/wiki/Policy > > There are a number of other policy decisions about the Haskell Platform > that we will need to make in the coming weeks and months. The platform > is supposed to be owned by and serve the interests of the community. As > such it is important that significant decisions have some kind of > community backing. The intention is that important issues are brought to > the libraries mailing list, debated there and decisions reached. > > To ensure that the relevant issues are indeed discussed and decisions > get made, we are proposing a steering committee. It would be the job of > the steering committee to see that the important issues are properly > discussed and decisions are made and recorded. > > It would be up to the committee to decide what issues to present, how to > start discussions and if necessary how to guide them. Here are some > examples of issues that the steering committee will likely want to bring > to the attention of this mailing list: > ? ? ?* general package quality requirements > ? ? ?* portability (OS and compiler/language) > ? ? ?* balance of quality vs quantity in libraries > ? ? ?* license requirements > ? ? ?* procedures for deciding which packages to add (or drop) > > It is not the intention that the committee members get much more say in > policy decisions than other active contributors to discussion on the > libraries mailing list. We hope therefore that the membership of the > committee does not need to be terribly formal. The only difficulty comes > when consensus cannot be reached on an issue where making some decision > is widely agreed to be better than making no decision. There is no > specified protocol for this situation at this stage. > > There would obviously have to be good communication between the steering > committee and the platform release team. The needs of the release team > will inform the issues that get discussed and obviously the libraries > list cannot mandate that the release team do the impractical. > > We are now seeking volunteers for this steering committee. A good number > is probably around five. > > Comments, criticisms and volunteers please! > > Duncan > > > PS. I'm going to be away 'til Sunday. > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From dons at galois.com Mon Jul 20 12:40:09 2009 From: dons at galois.com (Don Stewart) Date: Mon Jul 20 12:23:44 2009 Subject: PROPOSAL: Remove Control.OldException In-Reply-To: <5ab17e790907192327m504521b5h5b0c72ee303036d4@mail.gmail.com> References: <20090718125113.GA21683@matrix.chaos.earth.li> <20090718165104.GA6997@whirlpool.galois.com> <20090719172930.GA619@matrix.chaos.earth.li> <20090719185630.GA11801@whirlpool.galois.com> <5ab17e790907192327m504521b5h5b0c72ee303036d4@mail.gmail.com> Message-ID: <20090720164009.GF15846@whirlpool.galois.com> Ian, how about we dreprecate the module instead? -- Don iavor.diatchki: > Hello, > Please do not remove OldException. > -Iavor > > On Sun, Jul 19, 2009 at 9:56 PM, Don Stewart wrote: > > igloo: > >> On Sat, Jul 18, 2009 at 09:51:04AM -0700, Donald Bruce Stewart wrote: > >> > igloo: > >> > > > >> > > Hi all, > >> > > > >> > > Proposal: > >> > > ? ? Remove Control.OldException > >> > > ? ? http://hackage.haskell.org/trac/ghc/ticket/3381 > >> > > > >> > > We included Control.OldException in base to help people trying to remain > >> > > compatible with both GHC 6.8 and GHC 6.10. However, my impression is > >> > > that most (all?) people who wanted compatibility used the > >> > > extensible-exceptions package instead. > >> > > > >> > > >> > I'd be very wary of this so early. Try building hackage and tell us what > >> > breaks when there is no OldException. > >> > >> I don't have a reasonable way to do an all-of-hackage build at the > >> moment, but I've unpacked the latest version of each package and grepped > >> for "Control.OldException". Of the 1425 packages, 19 mention it: > >> > > > > Oh, I wonder how many are building with base 3 too. Hmm... we should > > check that. > > > > -- Don > > _______________________________________________ > > Libraries mailing list > > Libraries@haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > > From awick at galois.com Mon Jul 20 13:16:08 2009 From: awick at galois.com (Adam Wick) Date: Mon Jul 20 12:59:18 2009 Subject: Volunteers for a Haskell Platform steering committee Message-ID: <4A64A658.1000101@galois.com> > We are now seeking volunteers for this steering committee. If there's still space, I'd like to join up, if just to represent the interest of Galois's fairly large existing code base as well as our future development efforts. -Adam From wasserman.louis at gmail.com Mon Jul 20 14:33:52 2009 From: wasserman.louis at gmail.com (Louis Wasserman) Date: Mon Jul 20 14:15:45 2009 Subject: Proposal #3271: new methods for Data.Sequence In-Reply-To: <2518b95d0907191857q29a442b1l86609db8e3e58d17@mail.gmail.com> References: <2518b95d0907191857q29a442b1l86609db8e3e58d17@mail.gmail.com> Message-ID: Done. See the new patch here . Key notes: Among other things, I manually deforested the stable sorting algorithm, resulting in a moderate performance gain on simply using Data.List.sortBy. The current benchmarks indicate: - unstableSort is typically 40% faster than sort, with no RTS options. - With memory to spare, unstableSort is typically 15% faster than sort. - On sorted data with no RTS options, unstableSort is nearly 70% faster than sort. - On sorted data with memory to spare, unstableSort is nearly 60% faster than sort. (Did I mention I think pairing heaps are excellent?) Among all the methods I added to Data.Sequence, the most code-intensive are tails/inits and consDigitToTree/snocDigitToTree. The second was more intensively used with some previous zipWith implementations that have since been replaced, but they add moderate speed improvements to the significant amount of already-bulky code for appending two sequences, and I can live with that on my conscience. The code for tails/inits provides actual, concrete algorithmic benefits, in particular that evaluating a tail from the sequence of tails is O(log n), as opposed to O(n), but the entire tail sequence still only takes O(n) to build. In particular, evaluating one tail and then the tail just after it is still every bit as cheap as it should be. Finally, evaluating the whole sequence of tails with this method is even faster than scanr (<|) empty, or even a similar scanl, which is pretty nice. Louis Wasserman wasserman.louis@gmail.com On Sun, Jul 19, 2009 at 9:57 PM, Evan Laforge wrote: > > Again, I'd like to propose a compromise: make Data.Sequence.sortBy cmp be > > either fromList2 . Data.List.sortBy cmp . toList, or use the stable > > pairing-heap sort, and add a second sorting method, sortBy', that is > > unstable but faster. > > Sounds good to me but how about calling them unstableSortBy and > unstableSort? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090720/acc013de/attachment.html From ml at isaac.cedarswampstudios.org Mon Jul 20 14:47:15 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Mon Jul 20 14:29:00 2009 Subject: Volunteers for a Haskell Platform steering committee In-Reply-To: <4A64A658.1000101@galois.com> References: <4A64A658.1000101@galois.com> Message-ID: <4A64BBB3.8050401@isaac.cedarswampstudios.org> Adam Wick wrote: >> We are now seeking volunteers for this steering committee. > > If there's still space, I'd like to join up, if just to represent the > interest of Galois's fairly large existing code base as well as our > future development efforts. yes, that makes four of us so far (me) Isaac Dupree Thomas Schilling Iavor Diatchki Adam Wick don't forget to join mailing-list haskell-platform@projects.haskell.org at http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform Anyone else? It wouldn't hurt to have another volunteer (or two), but things aren't bad now either :-) -Isaac From johan.tibell at gmail.com Mon Jul 20 15:15:14 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon Jul 20 14:57:06 2009 Subject: Volunteers for a Haskell Platform steering committee In-Reply-To: <4A64BBB3.8050401@isaac.cedarswampstudios.org> References: <4A64A658.1000101@galois.com> <4A64BBB3.8050401@isaac.cedarswampstudios.org> Message-ID: <90889fe70907201215h23dd7fb5v57115fdf509f262@mail.gmail.com> On Mon, Jul 20, 2009 at 8:47 PM, Isaac Dupree < ml@isaac.cedarswampstudios.org> wrote: > Adam Wick wrote: > >> We are now seeking volunteers for this steering committee. >>> >> >> If there's still space, I'd like to join up, if just to represent the >> interest of Galois's fairly large existing code base as well as our >> future development efforts. >> > > yes, that makes four of us so far > (me) Isaac Dupree > Thomas Schilling > Iavor Diatchki > Adam Wick > And me! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090720/eb8cb63b/attachment.html From wasserman.louis at gmail.com Mon Jul 20 18:15:11 2009 From: wasserman.louis at gmail.com (Louis Wasserman) Date: Mon Jul 20 17:57:04 2009 Subject: Proposal #3271: new methods for Data.Sequence Message-ID: As a final addition to Data.Sequence, I've addedthe following methods. Possibly debatable design decisions are highlighted. - mapWithIndex :: (Int -> a -> b) -> Seq a -> Seq b. (This is based on mapAccumL, which is slightly suboptimal [as the full mapping must be done before the last element can be examined], but acceptable given the tiny code investment.) - elemIndex, elemIndices, findIndex, findIndices, all as in Data.List. - elemLastIndex, findLastIndex, elemIndicesDesc, findIndicesDesc, all working from right-to-left but otherwise analogous. **Note:**findIndicesDesc and elemIndicesDesc return lists, not Sequences, so as to permit maximum laziness. Moreover, both of those methods fuse well. - takeWhileEnd, dropWhileEnd, spanEnd, breakEnd, all of which work from right-to-left but otherwise perform as their Data.List analogues. * *Note:** spanEnd p xs, in particular, returns *first* the longest *suffix * of xs of elements satisfying p, and then the remaining prefix. All but mapWithIndex take O(i) time, where i is the appropriate breakpoint -- that is, they don't necessarily search the entire sequence. (Each of the xxxEnd methods take O(n-i).) None of these methods are particularly code-intensive, save for some rewrite-rules-based code that lets most of those methods be defined in terms of findIndex, without any performance loss. (In the absence of rewrite rules, the additional overhead is small.) Louis Wasserman wasserman.louis@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090720/337564ba/attachment.html From duncan.coutts at worc.ox.ac.uk Mon Jul 20 15:11:51 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jul 21 04:52:19 2009 Subject: PROPOSAL: Remove Control.OldException In-Reply-To: <5ab17e790907192327m504521b5h5b0c72ee303036d4@mail.gmail.com> References: <20090718125113.GA21683@matrix.chaos.earth.li> <20090718165104.GA6997@whirlpool.galois.com> <20090719172930.GA619@matrix.chaos.earth.li> <20090719185630.GA11801@whirlpool.galois.com> <5ab17e790907192327m504521b5h5b0c72ee303036d4@mail.gmail.com> Message-ID: <1248117111.3163.11.camel@localhost> On Mon, 2009-07-20 at 09:27 +0300, Iavor Diatchki wrote: > Hello, > Please do not remove OldException. > -Iavor Can you give any rationale? Are you trying to maintain compatibility with base-3 by using CPP + OldException? Is that significantly easier than using the extensible-exceptions package? Duncan From duncan.coutts at worc.ox.ac.uk Mon Jul 20 15:25:57 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jul 21 04:52:25 2009 Subject: Volunteers for a Haskell Platform steering committee In-Reply-To: <4A64BBB3.8050401@isaac.cedarswampstudios.org> References: <4A64A658.1000101@galois.com> <4A64BBB3.8050401@isaac.cedarswampstudios.org> Message-ID: <1248117957.3163.24.camel@localhost> On Mon, 2009-07-20 at 14:47 -0400, Isaac Dupree wrote: > Adam Wick wrote: > >> We are now seeking volunteers for this steering committee. > > > > If there's still space, I'd like to join up, if just to represent the > > interest of Galois's fairly large existing code base as well as our > > future development efforts. > yes, that makes four of us so far > (me) Isaac Dupree > Thomas Schilling > Iavor Diatchki > Adam Wick Johan Tibell also volunteered. > Anyone else? It wouldn't hurt to have another volunteer (or two), but > things aren't bad now either :-) I should have said at the beginning that I was also volunteering, partly as a communication link with the release team. So that'd make 6 which is within 5 +/- 1 :-) Does that all seem ok? I should point out again that the steering committee is not intended to have that much power when it comes to actual policy decisions, it's there to make sure that we as a community actually do make decisions one way or another on important policy issues affecting the platform. Interest groups can make their arguments directly on the libraries mailing list when issues are discussed. Duncan From johan.tibell at gmail.com Tue Jul 21 06:02:08 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue Jul 21 05:44:02 2009 Subject: Volunteers for a Haskell Platform steering committee In-Reply-To: <1248117957.3163.24.camel@localhost> References: <4A64A658.1000101@galois.com> <4A64BBB3.8050401@isaac.cedarswampstudios.org> <1248117957.3163.24.camel@localhost> Message-ID: <90889fe70907210302v32a5e5cbv50f2ec3ae5477859@mail.gmail.com> On Mon, Jul 20, 2009 at 9:25 PM, Duncan Coutts wrote: > On Mon, 2009-07-20 at 14:47 -0400, Isaac Dupree wrote: > > Adam Wick wrote: > > >> We are now seeking volunteers for this steering committee. > > > > > > If there's still space, I'd like to join up, if just to represent the > > > interest of Galois's fairly large existing code base as well as our > > > future development efforts. > > > yes, that makes four of us so far > > (me) Isaac Dupree > > Thomas Schilling > > Iavor Diatchki > > Adam Wick > > Johan Tibell also volunteered. > > > Anyone else? It wouldn't hurt to have another volunteer (or two), but > > things aren't bad now either :-) > > I should have said at the beginning that I was also volunteering, partly > as a communication link with the release team. > > So that'd make 6 which is within 5 +/- 1 :-) > > Does that all seem ok? > Yes. -- Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090721/412fe477/attachment.html From iavor.diatchki at gmail.com Wed Jul 22 03:19:39 2009 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed Jul 22 03:01:09 2009 Subject: PROPOSAL: Remove Control.OldException In-Reply-To: <1248117111.3163.11.camel@localhost> References: <20090718125113.GA21683@matrix.chaos.earth.li> <20090718165104.GA6997@whirlpool.galois.com> <20090719172930.GA619@matrix.chaos.earth.li> <20090719185630.GA11801@whirlpool.galois.com> <5ab17e790907192327m504521b5h5b0c72ee303036d4@mail.gmail.com> <1248117111.3163.11.camel@localhost> Message-ID: <5ab17e790907220019l2781997v3e1b8627b4fa0c7c@mail.gmail.com> Hello, On Mon, Jul 20, 2009 at 10:11 PM, Duncan Coutts wrote: > On Mon, 2009-07-20 at 09:27 +0300, Iavor Diatchki wrote: >> Hello, >> Please do not remove OldException. >> -Iavor > > Can you give any rationale? Are you trying to maintain compatibility > with base-3 by using CPP + OldException? Is that significantly easier > than using the extensible-exceptions package? 1. I would have to go and change all code that uses exceptions, again. 2. I am not sure how to write backwards compatible code. CPP + OldException is not pretty but it works. 3. The extensible exception package is not Haskell 98 (it uses existentials), so it really would be nice if _it_ was placed in a separate package. On that topic, it would be great if we had a way to see what are all the extensions used by a program (including those used by dependent packages). 4. Ian's proposal did not provide any motivation for this change. Is the benefit the we clean things up a bit? If so, I think that it is a bit soon to do it. -Iavor > > Duncan > > From marlowsd at gmail.com Wed Jul 22 06:43:59 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jul 22 06:25:29 2009 Subject: PROPOSAL: Remove Control.OldException In-Reply-To: <20090718125113.GA21683@matrix.chaos.earth.li> References: <20090718125113.GA21683@matrix.chaos.earth.li> Message-ID: <4A66ED6F.5090907@gmail.com> On 18/07/2009 13:51, Ian Lynagh wrote: > Hi all, > > Proposal: > Remove Control.OldException > http://hackage.haskell.org/trac/ghc/ticket/3381 > > We included Control.OldException in base to help people trying to remain > compatible with both GHC 6.8 and GHC 6.10. However, my impression is > that most (all?) people who wanted compatibility used the > extensible-exceptions package instead. > > I propose that we remove Control.OldException for GHC 6.12. > > If anyone does want Control.OldException, then it could be provided by a > separate package. > > Deadline: 2nd August (2 weeks). We're planning to have a base4-compat, right? So we could put Control.OldException in base-4, and leave it out of base-5. Cheers, Simon From awick at galois.com Wed Jul 22 11:31:39 2009 From: awick at galois.com (Adam Wick) Date: Wed Jul 22 11:13:14 2009 Subject: PROPOSAL: Remove Control.OldException In-Reply-To: <4A66ED6F.5090907@gmail.com> References: <20090718125113.GA21683@matrix.chaos.earth.li> <4A66ED6F.5090907@gmail.com> Message-ID: <2DC0F14C-BC3B-4ADC-9D4E-B2ACE8D5705B@galois.com> On Jul 22, 2009, at 3:43 AM, Simon Marlow wrote: > On 18/07/2009 13:51, Ian Lynagh wrote: >> >> Proposal: >> Remove Control.OldException >> http://hackage.haskell.org/trac/ghc/ticket/3381 > > We're planning to have a base4-compat, right? So we could put > Control.OldException in base-4, and leave it out of base-5. Why not leave it in base-4, mark it as deprecated (with all the attendant warnings) in base-5, and remove it from base-6? I can't imagine its inclusion is harming anything, and marking it as deprecated gives us all some warning before our packages suddenly break while updating. - Adam From qdunkan at gmail.com Wed Jul 22 15:13:53 2009 From: qdunkan at gmail.com (Evan Laforge) Date: Wed Jul 22 14:55:20 2009 Subject: PROPOSAL: Remove Control.OldException In-Reply-To: <2DC0F14C-BC3B-4ADC-9D4E-B2ACE8D5705B@galois.com> References: <20090718125113.GA21683@matrix.chaos.earth.li> <4A66ED6F.5090907@gmail.com> <2DC0F14C-BC3B-4ADC-9D4E-B2ACE8D5705B@galois.com> Message-ID: <2518b95d0907221213x686ba4a3m51d36f1297a0e533@mail.gmail.com> On Wed, Jul 22, 2009 at 8:31 AM, Adam Wick wrote: > On Jul 22, 2009, at 3:43 AM, Simon Marlow wrote: >> >> On 18/07/2009 13:51, Ian Lynagh wrote: >>> >>> Proposal: >>> ? ?Remove Control.OldException >>> ? ?http://hackage.haskell.org/trac/ghc/ticket/3381 >> >> We're planning to have a base4-compat, right? ?So we could put >> Control.OldException in base-4, and leave it out of base-5. > > Why not leave it in base-4, mark it as deprecated (with all the attendant > warnings) in base-5, and remove it from base-6? > > I can't imagine its inclusion is harming anything, and marking it as > deprecated gives us all some warning before our packages suddenly break > while updating. Python has a convention like this: version n -> new feature must be explicitly turned on, nonfatal warnings on things which will break version n+1 -> new feature implicitly on, old feature still available version n+2 -> old feature removed I think it's worked pretty well for them. So if ghc had done that, it would have looked something like: 6.10 -> extensible exceptions available under new library name, warnings attached to calls of 'try', 'handle', 'throwDyn', 'catchDyn', usage of Exception type, etc. 6.12 -> extensible exceptions go in Control.Exception, old ones move to OldException 6.14 -> OldException removed I recently went through the 6.8 to 6.10 upgrade, and while I did read about the changes on the list of course when I finally was forced to upgrade I'd forgotten about them. A whole stable version where the compiler emitted warnings would have given me plenty of time to fix at leisure, rather than suddenly becoming top priority because I'm blocking on upgrading some other package that needs 6.10. From niklas.broberg at gmail.com Thu Jul 23 07:36:33 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Thu Jul 23 07:26:15 2009 Subject: Proposal: ExplicitForall In-Reply-To: References: <638ABD0A29C8884A91BC5FB5C349B1C33F4BAAFDF9@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: > Alright, let's set an actual discussion period of 2 weeks for > ExplicitForall. If there is no opposition by then, we can add > ExplicitForall to the registered extensions in cabal as a first step. Slightly more than two weeks later, there has been no voices against and at least a few in favor. The attached patch for Cabal adds ExplicitForall to the Extension datatype, with documentation, and adds it to knownExtensions. Cheers, /Niklas -------------- next part -------------- A non-text attachment was scrubbed... Name: ExplicitForall.dpatch Type: application/octet-stream Size: 41637 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20090723/9e6fd5ac/ExplicitForall-0001.obj From jules at jellybean.co.uk Thu Jul 23 09:07:36 2009 From: jules at jellybean.co.uk (Jules Bean) Date: Thu Jul 23 08:49:03 2009 Subject: Data.Fixed.Fixed constructor In-Reply-To: References: Message-ID: <4A686098.8060601@jellybean.co.uk> Ashley Yakeley wrote: > I'm currently working on updating the Data.Fixed module in base. I am > adding Typeable and Data instances (automatically derived), and several > new HasResolution types (including one for 10^-2, monetary currencies > being an obvious Fixed use). Is an automatic Data instance wise? Morally speaking does a Data.Fixed really "include" a Integer? Compare the question: should the automatic Data instance for Complex a be used, since this exposes the fact that Complex is stored using two components in real/imaginary components? I think that abstract types like Complex and Fixed should be treated as atoms by Data rather than being traversable, but I'm not sure. Jules From ashley at semantic.org Thu Jul 23 15:29:40 2009 From: ashley at semantic.org (Ashley Yakeley) Date: Thu Jul 23 15:11:06 2009 Subject: Data.Fixed.Fixed constructor In-Reply-To: <4A686098.8060601@jellybean.co.uk> References: <4A686098.8060601@jellybean.co.uk> Message-ID: <1248377380.14293.4.camel@sherbourne> On Thu, 2009-07-23 at 14:07 +0100, Jules Bean wrote: > Ashley Yakeley wrote: > > I'm currently working on updating the Data.Fixed module in base. I am > > adding Typeable and Data instances (automatically derived), and several > > new HasResolution types (including one for 10^-2, monetary currencies > > being an obvious Fixed use). > > Is an automatic Data instance wise? > > Morally speaking does a Data.Fixed really "include" a Integer? > > Compare the question: should the automatic Data instance for Complex a > be used, since this exposes the fact that Complex is stored using two > components in real/imaginary components? > > I think that abstract types like Complex and Fixed should be treated as > atoms by Data rather than being traversable, but I'm not sure. Could you give me an example of a Data instance for either Complex or Fixed that you approve of? Data instances unavoidably expose concrete structure. That may be the actual internal structure of the type, or it may be some constructed concrete structure, but it must be something. -- Ashley Yakeley From dave at zednenem.com Thu Jul 23 22:06:11 2009 From: dave at zednenem.com (David Menendez) Date: Thu Jul 23 21:47:35 2009 Subject: Data.Fixed.Fixed constructor In-Reply-To: <1248377380.14293.4.camel@sherbourne> References: <4A686098.8060601@jellybean.co.uk> <1248377380.14293.4.camel@sherbourne> Message-ID: <49a77b7a0907231906x3ef8d780w9d8a06a527178e3f@mail.gmail.com> On Thu, Jul 23, 2009 at 3:29 PM, Ashley Yakeley wrote: > On Thu, 2009-07-23 at 14:07 +0100, Jules Bean wrote: >> Ashley Yakeley wrote: >> > I'm currently working on updating the Data.Fixed module in base. I am >> > adding Typeable and Data instances (automatically derived), and several >> > new HasResolution types (including one for 10^-2, monetary currencies >> > being an obvious Fixed use). >> >> Is an automatic Data instance wise? >> >> Morally speaking does a Data.Fixed really "include" a Integer? >> >> Compare the question: should the automatic Data instance for Complex a >> be used, since this exposes the fact that Complex is stored using two >> components in real/imaginary components? >> >> I think that abstract types like Complex and Fixed should be treated as >> atoms by Data rather than being traversable, but I'm not sure. > > Could you give me an example of a Data instance for either Complex or > Fixed that you approve of? > > Data instances unavoidably expose concrete structure. That may be the > actual internal structure of the type, or it may be some constructed > concrete structure, but it must be something. For Fixed, perhaps something along the lines of the Double instance? doubleType :: DataType doubleType = mkFloatType "Prelude.Double" instance Data Double where toConstr = mkFloatConstr floatType -- that should probably be "doubleType" gunfold _ z c = case constrRep c of (FloatConstr x) -> z x _ -> error "gunfold" dataTypeOf _ = doubleType You'd just need to insert some appropriate conversions between Double and Fixed. Alternatively, you could make Fixed non-representable like Ptr, instance Typeable a => Data (Ptr a) where toConstr _ = error "toConstr" gunfold _ _ = error "gunfold" dataTypeOf _ = mkNorepType "GHC.Ptr.Ptr" Note that both these instances use the default definition for gfoldl, which does not attempt to descend into the structure of the data. I think this is appropriate, although whoever wrote the instance for Ratio appears to disagree with me. -- Dave Menendez From dave at zednenem.com Thu Jul 23 22:53:09 2009 From: dave at zednenem.com (David Menendez) Date: Thu Jul 23 22:34:32 2009 Subject: Data.Fixed.Fixed constructor In-Reply-To: <49a77b7a0907231906x3ef8d780w9d8a06a527178e3f@mail.gmail.com> References: <4A686098.8060601@jellybean.co.uk> <1248377380.14293.4.camel@sherbourne> <49a77b7a0907231906x3ef8d780w9d8a06a527178e3f@mail.gmail.com> Message-ID: <49a77b7a0907231953t4247b265h570ebd580e69bd02@mail.gmail.com> On Thu, Jul 23, 2009 at 10:06 PM, David Menendez wrote: > On Thu, Jul 23, 2009 at 3:29 PM, Ashley Yakeley wrote: >> On Thu, 2009-07-23 at 14:07 +0100, Jules Bean wrote: >>> Ashley Yakeley wrote: >>> > I'm currently working on updating the Data.Fixed module in base. I am >>> > adding Typeable and Data instances (automatically derived), and several >>> > new HasResolution types (including one for 10^-2, monetary currencies >>> > being an obvious Fixed use). >>> >>> Is an automatic Data instance wise? >>> >>> Morally speaking does a Data.Fixed really "include" a Integer? >>> >>> Compare the question: should the automatic Data instance for Complex a >>> be used, since this exposes the fact that Complex is stored using two >>> components in real/imaginary components? >>> >>> I think that abstract types like Complex and Fixed should be treated as >>> atoms by Data rather than being traversable, but I'm not sure. >> >> Could you give me an example of a Data instance for either Complex or >> Fixed that you approve of? >> >> Data instances unavoidably expose concrete structure. That may be the >> actual internal structure of the type, or it may be some constructed >> concrete structure, but it must be something. > > For Fixed, perhaps something along the lines of the Double instance? > > doubleType :: DataType > doubleType = mkFloatType "Prelude.Double" > > instance Data Double where > ?toConstr = mkFloatConstr floatType ? -- that should probably be "doubleType" > ?gunfold _ z c = case constrRep c of > ? ? ? ? ? ? ? ? ? ?(FloatConstr x) -> z x > ? ? ? ? ? ? ? ? ? ?_ -> error "gunfold" > ?dataTypeOf _ = doubleType > > You'd just need to insert some appropriate conversions between Double and Fixed. > > Alternatively, you could make Fixed non-representable like Ptr, > > instance Typeable a => Data (Ptr a) where > ?toConstr _ ? = error "toConstr" > ?gunfold _ _ ?= error "gunfold" > ?dataTypeOf _ = mkNorepType "GHC.Ptr.Ptr" > > Note that both these instances use the default definition for gfoldl, > which does not attempt to descend into the structure of the data. I > think this is appropriate, although whoever wrote the instance for > Ratio appears to disagree with me. I just checked the second SYB paper, , and in section 5.2 it discusses primitive types. Based on that, I think StringRep is the most correct solution. Here's a quick sketch that seems to work: > import Data.Typeable > import Data.Data > import Data.Fixed > > instance (HasResolution a) => Typeable (Fixed a) where > -- omitted > > fixedType :: DataType > fixedType = mkStringType "Data.Fixed.Fixed" > > instance (HasResolution a) => Data (Fixed a) where > toConstr x = mkStringConstr fixedType (show x) > dataTypeOf _ = fixedType > > gunfold _ z c = case constrRep c of > StringConstr s -> z (readFixed s) > _ -> error "gunfold" > > readFixed :: HasResolution a => String -> Fixed a > readFixed s = realToFrac x > where > x :: Double > x = read s -- Dave Menendez From ashley at semantic.org Thu Jul 23 23:21:31 2009 From: ashley at semantic.org (Ashley Yakeley) Date: Thu Jul 23 23:02:55 2009 Subject: Data.Fixed.Fixed constructor In-Reply-To: <49a77b7a0907231906x3ef8d780w9d8a06a527178e3f@mail.gmail.com> References: <4A686098.8060601@jellybean.co.uk> <1248377380.14293.4.camel@sherbourne> <49a77b7a0907231906x3ef8d780w9d8a06a527178e3f@mail.gmail.com> Message-ID: <4A6928BB.2060007@semantic.org> David Menendez wrote: > instance Data Double where > toConstr = mkFloatConstr floatType -- that should probably be "doubleType" > gunfold _ z c = case constrRep c of > (FloatConstr x) -> z x > _ -> error "gunfold" > dataTypeOf _ = doubleType I could do something like this for Fixed, but deriving Fixed automatically does essentially the same thing. > Alternatively, you could make Fixed non-representable like Ptr, Why? Fixed morally is data. -- Ashley Yakeley From dave at zednenem.com Fri Jul 24 00:58:43 2009 From: dave at zednenem.com (David Menendez) Date: Fri Jul 24 00:40:06 2009 Subject: Data.Fixed.Fixed constructor In-Reply-To: <4A6928BB.2060007@semantic.org> References: <4A686098.8060601@jellybean.co.uk> <1248377380.14293.4.camel@sherbourne> <49a77b7a0907231906x3ef8d780w9d8a06a527178e3f@mail.gmail.com> <4A6928BB.2060007@semantic.org> Message-ID: <49a77b7a0907232158u2dd6a0e5k8e58a233c9494238@mail.gmail.com> On Thu, Jul 23, 2009 at 11:21 PM, Ashley Yakeley wrote: > David Menendez wrote: > >> instance Data Double where >> ?toConstr = mkFloatConstr floatType ? -- that should probably be >> "doubleType" >> ?gunfold _ z c = case constrRep c of >> ? ? ? ? ? ? ? ? ? ?(FloatConstr x) -> z x >> ? ? ? ? ? ? ? ? ? ?_ -> error "gunfold" >> ?dataTypeOf _ = doubleType > > I could do something like this for Fixed, but deriving Fixed automatically > does essentially the same thing. It depends on how abstract you want Fixed to be. If you use the derived Data instances, then gshow and gread (from Data.Generics.Text) expose the implementation. *Fixed Data.Generics.Text> gshow (4::Micro) "(MkFixed (4000000))" *Fixed Data.Generics.Text> gread "(MkFixed (4))" :: [(Micro,String)] [(0.000004,"")] *Fixed Data.Generics.Text> gread "(MkFixed (4))" :: [(Pico,String)] [(0.000000000004,"")] In contrast, the StringRep version I posted elsewhere works fine with gshow/gread while still hiding the implementation. *Main Data.Generics.Text> gshow (4::Micro) "(4.000000)" *Main Data.Generics.Text> gread "(4)" :: [(Micro,String)] [(4.000000,"")] *Main Data.Generics.Text> gread "(4)" :: [(Pico,String)] [(4.000000000000,"")] -- Dave Menendez From ashley at semantic.org Fri Jul 24 01:44:05 2009 From: ashley at semantic.org (Ashley Yakeley) Date: Fri Jul 24 01:25:29 2009 Subject: Data.Fixed.Fixed constructor In-Reply-To: <49a77b7a0907232158u2dd6a0e5k8e58a233c9494238@mail.gmail.com> References: <4A686098.8060601@jellybean.co.uk> <1248377380.14293.4.camel@sherbourne> <49a77b7a0907231906x3ef8d780w9d8a06a527178e3f@mail.gmail.com> <4A6928BB.2060007@semantic.org> <49a77b7a0907232158u2dd6a0e5k8e58a233c9494238@mail.gmail.com> Message-ID: <1248414245.27793.1.camel@glastonbury> On Fri, 2009-07-24 at 00:58 -0400, David Menendez wrote: > It depends on how abstract you want Fixed to be. If you use the > derived Data instances, then gshow and gread (from Data.Generics.Text) > expose the implementation. But I'm going to expose the MkFixed constructor anyway. What's lost with a derived instance? -- Ashley Yakeley From dave at zednenem.com Fri Jul 24 02:03:52 2009 From: dave at zednenem.com (David Menendez) Date: Fri Jul 24 01:45:14 2009 Subject: Data.Fixed.Fixed constructor In-Reply-To: <1248414245.27793.1.camel@glastonbury> References: <4A686098.8060601@jellybean.co.uk> <1248377380.14293.4.camel@sherbourne> <49a77b7a0907231906x3ef8d780w9d8a06a527178e3f@mail.gmail.com> <4A6928BB.2060007@semantic.org> <49a77b7a0907232158u2dd6a0e5k8e58a233c9494238@mail.gmail.com> <1248414245.27793.1.camel@glastonbury> Message-ID: <49a77b7a0907232303r4109d870sa68fbcca70e2a161@mail.gmail.com> On Fri, Jul 24, 2009 at 1:44 AM, Ashley Yakeley wrote: > On Fri, 2009-07-24 at 00:58 -0400, David Menendez wrote: > >> It depends on how abstract you want Fixed to be. If you use the >> derived Data instances, then gshow and gread (from Data.Generics.Text) >> expose the implementation. > > But I'm going to expose the MkFixed constructor anyway. What's lost with > a derived instance? If the constructor is already exposed, then you don't lose abstraction with a derived instance. Out of curiosity, what made you decide to expose the constructor? -- Dave Menendez From ashley at semantic.org Fri Jul 24 02:13:26 2009 From: ashley at semantic.org (Ashley Yakeley) Date: Fri Jul 24 01:54:53 2009 Subject: Data.Fixed.Fixed constructor In-Reply-To: <49a77b7a0907232303r4109d870sa68fbcca70e2a161@mail.gmail.com> References: <4A686098.8060601@jellybean.co.uk> <1248377380.14293.4.camel@sherbourne> <49a77b7a0907231906x3ef8d780w9d8a06a527178e3f@mail.gmail.com> <4A6928BB.2060007@semantic.org> <49a77b7a0907232158u2dd6a0e5k8e58a233c9494238@mail.gmail.com> <1248414245.27793.1.camel@glastonbury> <49a77b7a0907232303r4109d870sa68fbcca70e2a161@mail.gmail.com> Message-ID: <1248416006.27793.10.camel@glastonbury> On Fri, 2009-07-24 at 02:03 -0400, David Menendez wrote: > If the constructor is already exposed, then you don't lose abstraction > with a derived instance. > > Out of curiosity, what made you decide to expose the constructor? As a general rule, if there is a correct Data instance, then it is always possible to recreate the constructors. Since I am providing a Data instance, I might as well provide the MkFixed constructor. Consider: your Data instance is StringRep-based. My automatically derived one is Integer-based. Both suggest concrete representations, but the Integer one makes much more sense to me. And as it happens, that's the actual concrete representation. -- Ashley Yakeley From jules at jellybean.co.uk Fri Jul 24 07:13:59 2009 From: jules at jellybean.co.uk (Jules Bean) Date: Fri Jul 24 06:55:22 2009 Subject: Data.Fixed.Fixed constructor In-Reply-To: <1248414245.27793.1.camel@glastonbury> References: <4A686098.8060601@jellybean.co.uk> <1248377380.14293.4.camel@sherbourne> <49a77b7a0907231906x3ef8d780w9d8a06a527178e3f@mail.gmail.com> <4A6928BB.2060007@semantic.org> <49a77b7a0907232158u2dd6a0e5k8e58a233c9494238@mail.gmail.com> <1248414245.27793.1.camel@glastonbury> Message-ID: <4A699777.8090009@jellybean.co.uk> Ashley Yakeley wrote: > On Fri, 2009-07-24 at 00:58 -0400, David Menendez wrote: > >> It depends on how abstract you want Fixed to be. If you use the >> derived Data instances, then gshow and gread (from Data.Generics.Text) >> expose the implementation. > > But I'm going to expose the MkFixed constructor anyway. What's lost with > a derived instance? > What's lost is that if I have the user-defined type: data Foo = Foo Integer Micro and I use, for example "everywhere" on it, then my everywhere functionn gets applied to the secret Integer subterm inside Fixed. For example: everywhere (mkT ((+1) :: Integer -> Integer)) (I hope I got this right, I'm very rusty on the details of generics) is intended to add one to all Integer subterms - and only Integer subterms - no matter how deep they are. When this actually alters the integer inside my Micro, I'm going to be pretty surprised. Or maybe I'm not that surprised, but the point is, it exposes the internals of Fixed. It's an abstraction hole. Jules From naesten at gmail.com Fri Jul 24 11:26:58 2009 From: naesten at gmail.com (Samuel Bronson) Date: Fri Jul 24 11:08:22 2009 Subject: Proposal: ExplicitForall In-Reply-To: References: <638ABD0A29C8884A91BC5FB5C349B1C33F4BAAFDF9@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: On Thu, Jul 23, 2009 at 7:36 AM, Niklas Broberg wrote: >> Alright, let's set an actual discussion period of 2 weeks for >> ExplicitForall. If there is no opposition by then, we can add >> ExplicitForall to the registered extensions in cabal as a first step. > > Slightly more than two weeks later, there has been no voices against > and at least a few in favor. Huh. I guess I forgot I could reply? In favour I am. (Even if I do live in the US. ) From igloo at earth.li Fri Jul 24 11:32:04 2009 From: igloo at earth.li (Ian Lynagh) Date: Fri Jul 24 11:13:27 2009 Subject: PROPOSAL: export copyPermissions from System.Directory Message-ID: <20090724153204.GA9260@matrix.chaos.earth.li> Hi all, This proposal is: export copyPermissions from System.Directory http://hackage.haskell.org/trac/ghc/ticket/3392 (originally part of http://hackage.haskell.org/trac/ghc/ticket/2610) The copyPermissions :: FilePath -> FilePath -> IO () function (currently an internal function) should be exported from System.Directory. It is not the same as getPermissions s >>= setPermissions d as the Permissions type this uses is lossy. Deadline: 8th August (2 weeks). Thanks Ian From igloo at earth.li Fri Jul 24 12:44:27 2009 From: igloo at earth.li (Ian Lynagh) Date: Fri Jul 24 12:25:49 2009 Subject: PROPOSAL: Add openFileTemplate, openBinaryFileTemplate to System.IO Message-ID: <20090724164427.GA13350@matrix.chaos.earth.li> Hi all, This is Add openFileTemplate, openBinaryFileTemplate to System.IO http://hackage.haskell.org/trac/ghc/ticket/3393 (originally part of http://hackage.haskell.org/trac/ghc/ticket/2610) In System.IO, openTempFile and openBinaryTempFile mask the file permissions of the file they create with 0o600. However, we would like to use it for implementing things like writeFileAtomic, in which case we want the default file permissions to be used. I propose that we add openFileTemplate and openBinaryFileTemplate functions, which use the default permissions. Deadline: 8th August (2 weeks). Thanks Ian From marco-oweber at gmx.de Fri Jul 24 16:47:03 2009 From: marco-oweber at gmx.de (Marc Weber) Date: Fri Jul 24 16:28:26 2009 Subject: hasktags enhancements ? How to contribute? Message-ID: <1248464435-sup-1772@nixos> Hi, more than a year ago I enhanced hasktags. Now I had another look at my code ensuring that it finds at least as many tags as the hackage implementation does. It also adds a small test suite ensuring progress. So let me know how well it works for you. If some tags aren't found send me a test case so that I can add it to the test suite. Where to get it from: darcs get http://mawercer.de/~marc/my-hasktags So what's different ? - it finds more tags (see details below) - it adds tag kinds (vim only) Example: SpacingCombiningMark ./2/testcase2.hs 154;" cons Surrogate ./2/testcase2.hs 175;" cons TitlecaseLetter ./2/testcase2.hs 150;" cons UppercaseLetter ./2/testcase2.hs 148;" d digitToInt ./2/testcase2.hs 131;" ft digitToInt ./2/testcase2.hs 132;" fi cons = contstructor ft = funtion type fi = function implementation m = module - adds the flag --ignore-close-implementation eg if you have abc,def :: Int abc = 7 {- 20 line comment .. -} def = 8 abc is added once (because the type definition and the implementation is very close) but def is added twice because you may want to jump to either one directly. That's important because :tjump (vim) won't bother you asking you which one to take. So the list of tags is shorter in general. details about finding more tags: a) it finds more tags -> [1] Example (by testcase) 1) module Main where import Text.JSON func = ... using this strange indentation the hackage hasktags fails horribly (test case 1) 2) from Data.Char #ifndef __GLASGOW_HASKELL__ isAsciiUpper, isAsciiLower :: Char -> Bool isAsciiLower c = c >= 'a' && c <= 'z' isAsciiUpper c = c >= 'A' && c <= 'Z' #endif this isAsciiUpper isn't found by the hackage version for some reason 4) the basic rootLoggerName isn't found! module System.Log.Logger rootLoggerName = "" 5) Saying those aren't found isn't quite true. the hackage version just doesn't remove the parenthesis and adds (@?) to the tag file. 8) ABCD isn't found because of this parenthesis class (Show a) => (ABCD a) where Again (ABCD is found instead. You can test this yourself by running my testsuite (cd testcases; sh test.sh) Marc Weber From nominolo at googlemail.com Fri Jul 24 19:27:04 2009 From: nominolo at googlemail.com (Thomas Schilling) Date: Fri Jul 24 19:08:44 2009 Subject: PROPOSAL: Add openFileTemplate, openBinaryFileTemplate to System.IO In-Reply-To: <20090724164427.GA13350@matrix.chaos.earth.li> References: <20090724164427.GA13350@matrix.chaos.earth.li> Message-ID: <916b84820907241627o4c7c07f0wc36a9dd006eb28cc@mail.gmail.com> Sorry, I don't get this. I thought the "temp" in openTempFile stood for "temporary" not "template". And what would the signature of these new functions would look like and what exactly they would do. 2009/7/24 Ian Lynagh : > > Hi all, > > This is > ? ?Add openFileTemplate, openBinaryFileTemplate to System.IO > ? ?http://hackage.haskell.org/trac/ghc/ticket/3393 > ? ?(originally part of http://hackage.haskell.org/trac/ghc/ticket/2610) > > In System.IO, openTempFile and openBinaryTempFile mask the file > permissions of the file they create with 0o600. However, we would like > to use it for implementing things like writeFileAtomic, in which case we > want the default file permissions to be used. > > I propose that we add openFileTemplate and openBinaryFileTemplate > functions, which use the default permissions. > > Deadline: 8th August (2 weeks). > > > Thanks > Ian > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -- Push the envelope. Watch it bend. From ashley at semantic.org Fri Jul 24 19:28:30 2009 From: ashley at semantic.org (Ashley Yakeley) Date: Fri Jul 24 19:09:53 2009 Subject: Data.Fixed.Fixed constructor In-Reply-To: <4A699777.8090009@jellybean.co.uk> References: <4A686098.8060601@jellybean.co.uk> <1248377380.14293.4.camel@sherbourne> <49a77b7a0907231906x3ef8d780w9d8a06a527178e3f@mail.gmail.com> <4A6928BB.2060007@semantic.org> <49a77b7a0907232158u2dd6a0e5k8e58a233c9494238@mail.gmail.com> <1248414245.27793.1.camel@glastonbury> <4A699777.8090009@jellybean.co.uk> Message-ID: <1248478110.791.231.camel@sherbourne> On Fri, 2009-07-24 at 12:13 +0100, Jules Bean wrote: > When this actually alters the integer inside my Micro, I'm going to be > pretty surprised. > > Or maybe I'm not that surprised, but the point is, it exposes the > internals of Fixed. It's an abstraction hole. The whole point of SYB is to break abstraction. A "subterm" is a rather vague concept, and it makes a rather arbitrary distinction between "loosely holding" the contained value (will be touched by 'everywhere') and "tightly using" it (won't be touched). Does Complex hold or use its real and imaginary parts? Does Ratio hold or use its numerator and denominator? In both cases, the whole means something more than the aggregate of its parts, but this is typically the case with data-types. If you want a data-type that means nothing more than "aggregate", us (,) tuples. Generally I recommend KYB if you care about abstraction, because YB is actually meaningful code that should not be Sd. -- Ashley Yakeley From noteed at gmail.com Sat Jul 25 01:28:09 2009 From: noteed at gmail.com (minh thu) Date: Sat Jul 25 01:09:50 2009 Subject: PROPOSAL: Add openFileTemplate, openBinaryFileTemplate to System.IO In-Reply-To: <916b84820907241627o4c7c07f0wc36a9dd006eb28cc@mail.gmail.com> References: <20090724164427.GA13350@matrix.chaos.earth.li> <916b84820907241627o4c7c07f0wc36a9dd006eb28cc@mail.gmail.com> Message-ID: <40a414c20907242228n897b656xbb5f561352d9f0fb@mail.gmail.com> Hi, "Temp" is indeed for "temporary" but the function still takes a template as parameters. The proposal seems to be to to have a similar function, one that also uses a template, but with the default permissions, not those of a temporary file create by the existing functions. Cheers, Thu 2009/7/25 Thomas Schilling : > Sorry, I don't get this. I thought the "temp" in openTempFile stood > for "temporary" not "template". And what would the signature of these > new functions would look like and what exactly they would do. > > 2009/7/24 Ian Lynagh : >> >> Hi all, >> >> This is >> Add openFileTemplate, openBinaryFileTemplate to System.IO >> http://hackage.haskell.org/trac/ghc/ticket/3393 >> (originally part of http://hackage.haskell.org/trac/ghc/ticket/2610) >> >> In System.IO, openTempFile and openBinaryTempFile mask the file >> permissions of the file they create with 0o600. However, we would like >> to use it for implementing things like writeFileAtomic, in which case we >> want the default file permissions to be used. >> >> I propose that we add openFileTemplate and openBinaryFileTemplate >> functions, which use the default permissions. >> >> Deadline: 8th August (2 weeks). >> >> >> Thanks >> Ian >> >> _______________________________________________ >> Libraries mailing list >> Libraries@haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> > > > > -- > Push the envelope. Watch it bend. > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From qdunkan at gmail.com Sat Jul 25 02:00:19 2009 From: qdunkan at gmail.com (Evan Laforge) Date: Sat Jul 25 01:41:39 2009 Subject: PROPOSAL: Add openFileTemplate, openBinaryFileTemplate to System.IO In-Reply-To: <40a414c20907242228n897b656xbb5f561352d9f0fb@mail.gmail.com> References: <20090724164427.GA13350@matrix.chaos.earth.li> <916b84820907241627o4c7c07f0wc36a9dd006eb28cc@mail.gmail.com> <40a414c20907242228n897b656xbb5f561352d9f0fb@mail.gmail.com> Message-ID: <2518b95d0907242300i4302d939od4bc1671e4fe462f@mail.gmail.com> I've never heard this usage of the word "template" before, so I guessed it was meant to open some kind of template file. openWithMode? openWithPermissions? From noteed at gmail.com Sat Jul 25 02:02:35 2009 From: noteed at gmail.com (minh thu) Date: Sat Jul 25 01:44:16 2009 Subject: PROPOSAL: Add openFileTemplate, openBinaryFileTemplate to System.IO In-Reply-To: <2518b95d0907242300i4302d939od4bc1671e4fe462f@mail.gmail.com> References: <20090724164427.GA13350@matrix.chaos.earth.li> <916b84820907241627o4c7c07f0wc36a9dd006eb28cc@mail.gmail.com> <40a414c20907242228n897b656xbb5f561352d9f0fb@mail.gmail.com> <2518b95d0907242300i4302d939od4bc1671e4fe462f@mail.gmail.com> Message-ID: <40a414c20907242302i49403d50g99588c4a4b041fa@mail.gmail.com> 2009/7/25 Evan Laforge : > I've never heard this usage of the word "template" before, so I > guessed it was meant to open some kind of template file. > openWithMode? openWithPermissions? man mktemp for instance: http://www.manpagez.com/man/1/mktemp/ Thu From qdunkan at gmail.com Sat Jul 25 02:11:40 2009 From: qdunkan at gmail.com (Evan Laforge) Date: Sat Jul 25 01:52:59 2009 Subject: PROPOSAL: Add openFileTemplate, openBinaryFileTemplate to System.IO In-Reply-To: <40a414c20907242302i49403d50g99588c4a4b041fa@mail.gmail.com> References: <20090724164427.GA13350@matrix.chaos.earth.li> <916b84820907241627o4c7c07f0wc36a9dd006eb28cc@mail.gmail.com> <40a414c20907242228n897b656xbb5f561352d9f0fb@mail.gmail.com> <2518b95d0907242300i4302d939od4bc1671e4fe462f@mail.gmail.com> <40a414c20907242302i49403d50g99588c4a4b041fa@mail.gmail.com> Message-ID: <2518b95d0907242311u1b1a3954uaf29c955ab7f3cb2@mail.gmail.com> On Fri, Jul 24, 2009 at 11:02 PM, minh thu wrote: > 2009/7/25 Evan Laforge : >> I've never heard this usage of the word "template" before, so I >> guessed it was meant to open some kind of template file. >> openWithMode? ?openWithPermissions? > > man mktemp Ohhh, it's for the filename, sorry, all the talk about permissions got me on the wrong track. From igloo at earth.li Sat Jul 25 08:35:33 2009 From: igloo at earth.li (Ian Lynagh) Date: Sat Jul 25 08:16:54 2009 Subject: PROPOSAL: Add openFileTemplate, openBinaryFileTemplate to System.IO In-Reply-To: <2518b95d0907242311u1b1a3954uaf29c955ab7f3cb2@mail.gmail.com> References: <20090724164427.GA13350@matrix.chaos.earth.li> <916b84820907241627o4c7c07f0wc36a9dd006eb28cc@mail.gmail.com> <40a414c20907242228n897b656xbb5f561352d9f0fb@mail.gmail.com> <2518b95d0907242300i4302d939od4bc1671e4fe462f@mail.gmail.com> <40a414c20907242302i49403d50g99588c4a4b041fa@mail.gmail.com> <2518b95d0907242311u1b1a3954uaf29c955ab7f3cb2@mail.gmail.com> Message-ID: <20090725123533.GA12044@matrix.chaos.earth.li> On Fri, Jul 24, 2009 at 11:11:40PM -0700, Evan Laforge wrote: > On Fri, Jul 24, 2009 at 11:02 PM, minh thu wrote: > > 2009/7/25 Evan Laforge : > >> I've never heard this usage of the word "template" before, so I > >> guessed it was meant to open some kind of template file. > >> openWithMode? ?openWithPermissions? > > > > man mktemp > > Ohhh, it's for the filename, sorry, all the talk about permissions got > me on the wrong track. Right. Just to clarify for anyone else reading, we currently have: openTempFile :: FilePath -> String -> IO (FilePath, Handle) openBinaryTempFile :: FilePath -> String -> IO (FilePath, Handle) which mask the mode, and we would add openFileTemplate :: FilePath -> String -> IO (FilePath, Handle) openBinaryFileTemplate :: FilePath -> String -> IO (FilePath, Handle) which do not. Theese functions are used like this: openFileTemplate "/foo/bar" "bazXXX.ext" and open a file called "baz143.ext". "bazXXX.ext" is the template. Thanks Ian From gale at sefer.org Sun Jul 26 07:54:35 2009 From: gale at sefer.org (Yitzchak Gale) Date: Sun Jul 26 07:36:11 2009 Subject: Data.Fixed.Fixed constructor In-Reply-To: <1248416006.27793.10.camel@glastonbury> References: <4A686098.8060601@jellybean.co.uk> <1248377380.14293.4.camel@sherbourne> <49a77b7a0907231906x3ef8d780w9d8a06a527178e3f@mail.gmail.com> <4A6928BB.2060007@semantic.org> <49a77b7a0907232158u2dd6a0e5k8e58a233c9494238@mail.gmail.com> <1248414245.27793.1.camel@glastonbury> <49a77b7a0907232303r4109d870sa68fbcca70e2a161@mail.gmail.com> <1248416006.27793.10.camel@glastonbury> Message-ID: <2608b8a80907260454r2edc3e29ka6ab52d3e8645ec@mail.gmail.com> David Menendez wrote: >> Out of curiosity, what made you decide to expose the constructor? Ashley Yakeley wrote: > Since I am providing a Data instance, I might as well > provide the MkFixed constructor. So what? Most of the time the Data instance won't be used. Please don't do this, unless you think there might be a real use case. People want to be able to look at the haddocks/export list and see at a glance how to write neat, bullet-proof code. If someone uses the Data instance, they should be aware of the risks. But if you expose the constructor, it will cause average users of this module to do the wrong thing sometimes. Thanks, Yitz From dons at galois.com Sun Jul 26 19:02:56 2009 From: dons at galois.com (Don Stewart) Date: Sun Jul 26 18:44:13 2009 Subject: Haskell Platform progress report Message-ID: <5aad7f810907261602k694c84bao80a57cf41f9c72ec@mail.gmail.com> I've tried to summarise the last 3 months of HP activity: http://donsbot.wordpress.com/2009/07/26/haskell-platform-progress-report/ Including download statistics to inspire the packaging teams prior to this week's release :-) -- Don From jules at jellybean.co.uk Mon Jul 27 11:32:48 2009 From: jules at jellybean.co.uk (Jules Bean) Date: Mon Jul 27 11:14:02 2009 Subject: Data.Fixed.Fixed constructor In-Reply-To: <1248478110.791.231.camel@sherbourne> References: <4A686098.8060601@jellybean.co.uk> <1248377380.14293.4.camel@sherbourne> <49a77b7a0907231906x3ef8d780w9d8a06a527178e3f@mail.gmail.com> <4A6928BB.2060007@semantic.org> <49a77b7a0907232158u2dd6a0e5k8e58a233c9494238@mail.gmail.com> <1248414245.27793.1.camel@glastonbury> <4A699777.8090009@jellybean.co.uk> <1248478110.791.231.camel@sherbourne> Message-ID: <4A6DC8A0.7050709@jellybean.co.uk> Ashley Yakeley wrote: > On Fri, 2009-07-24 at 12:13 +0100, Jules Bean wrote: >> When this actually alters the integer inside my Micro, I'm going to be >> pretty surprised. >> >> Or maybe I'm not that surprised, but the point is, it exposes the >> internals of Fixed. It's an abstraction hole. > > The whole point of SYB is to break abstraction. A "subterm" is a rather > vague concept, and it makes a rather arbitrary distinction between > "loosely holding" the contained value (will be touched by 'everywhere') > and "tightly using" it (won't be touched). I disagree with you entirely and completely. I've made my argument and there is nothing more to add. You can ignore it if you wish. The whole point of SYB is not to break abstraction. A Data instance for Data.Fixed which exposes the Integer inside would render it useless for the kind of things I expect people do with SYB. Jules From ashley at semantic.org Mon Jul 27 13:32:55 2009 From: ashley at semantic.org (Ashley Yakeley) Date: Mon Jul 27 13:14:09 2009 Subject: Data.Fixed.Fixed constructor In-Reply-To: <4A6DC8A0.7050709@jellybean.co.uk> References: <4A686098.8060601@jellybean.co.uk> <1248377380.14293.4.camel@sherbourne> <49a77b7a0907231906x3ef8d780w9d8a06a527178e3f@mail.gmail.com> <4A6928BB.2060007@semantic.org> <49a77b7a0907232158u2dd6a0e5k8e58a233c9494238@mail.gmail.com> <1248414245.27793.1.camel@glastonbury> <4A699777.8090009@jellybean.co.uk> <1248478110.791.231.camel@sherbourne> <4A6DC8A0.7050709@jellybean.co.uk> Message-ID: <1248715975.31787.8.camel@glastonbury> On Mon, 2009-07-27 at 16:32 +0100, Jules Bean wrote: > The whole point of SYB is not to break abstraction. > > A Data instance for Data.Fixed which exposes the Integer inside would > render it useless for the kind of things I expect people do with SYB. Um, well I'm just doing the same thing as Complex and Ratio. They also expose their constructors explicitly and both their Data instances expose their constituent parts. And a Fixed really does contain an Integer, just as Rational contains two. -- Ashley Yakeley From briqueabraque at yahoo.com Mon Jul 27 14:15:26 2009 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Mon Jul 27 13:56:53 2009 Subject: ANN: bindings-common 0.2.1 Message-ID: bindings-* packages provide low level bindings to well known foreign libraries like sqlite3 and libusb. They are supposed to be used by high level module developers who needs special functionality already available outside Haskell. Natural examples of such modules would be higher level versions of such bindings. bindings-common offers basic code that makes writing such packages easier, and provide a common design standard. http://hackage.haskell.org/package/bindings-common The major new feature of this release is the availability of hsc2hs custom macros, and a corresponding big reduction in code size. As an example, the code below is all that is necessary to write a Haskell version of a C struct, with Storable instance: -- This is 'hostent' struct from posix : #bindings_starttype struct hostent #bindings_field h_name , CString #bindings_field h_aliases , Ptr CString #bindings_field h_addrtype , CInt #bindings_field h_length , CInt #bindings_field h_addr_list , Ptr CString #bindings_stoptype _ That results in http://hackage.haskell.org/packages/archive/bindings-posix/0.0.2/doc/html/Bindings-Posix.html#t%3AHostent Those hsc2hs macros have been used to map the standard C library (see module Bindings.C), as well as posix standard library (in a separate package), and are made available to modules depending on bindings-common. Best, Maur?cio From briqueabraque at yahoo.com Mon Jul 27 14:16:23 2009 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Mon Jul 27 14:01:16 2009 Subject: ANN: bindings-posix 0.0.2 Message-ID: bindings-posix is a low level binding to Posix. http://hackage.haskell.org/package/bindings-posix It is part of bindings-* packages, and makes use of facilities and design from package bindings-common to map the standard Posix library as described in this page: http://www.opengroup.org/onlinepubs/9699919799/basedefs/contents.html The major drawback is that it bindings to the Posix instance that runs on my computer (and probably most computers using ghc and gcc). However, if there's interest, I can add support to various layers of Posix if someone with knowledge of Posix helps me with environment variables I should use to (de)activate specific functionality. Best, Maur?cio From ashley at semantic.org Mon Jul 27 18:34:03 2009 From: ashley at semantic.org (Ashley Yakeley) Date: Mon Jul 27 18:15:18 2009 Subject: Data.Fixed.Fixed constructor In-Reply-To: <2608b8a80907260454r2edc3e29ka6ab52d3e8645ec@mail.gmail.com> References: <4A686098.8060601@jellybean.co.uk> <1248377380.14293.4.camel@sherbourne> <49a77b7a0907231906x3ef8d780w9d8a06a527178e3f@mail.gmail.com> <4A6928BB.2060007@semantic.org> <49a77b7a0907232158u2dd6a0e5k8e58a233c9494238@mail.gmail.com> <1248414245.27793.1.camel@glastonbury> <49a77b7a0907232303r4109d870sa68fbcca70e2a161@mail.gmail.com> <1248416006.27793.10.camel@glastonbury> <2608b8a80907260454r2edc3e29ka6ab52d3e8645ec@mail.gmail.com> Message-ID: <1248734043.3651.1.camel@sherbourne> On Sun, 2009-07-26 at 14:54 +0300, Yitzchak Gale wrote: > People want to be able to look at the haddocks/export list > and see at a glance how to write neat, bullet-proof code. > If someone uses the Data instance, they should be aware > of the risks. But if you expose the constructor, it will > cause average users of this module to do the wrong thing > sometimes. I'm not really seeing the problem, here. Ratio exposes its constructor, and Fixed is much like Rational with a fixed denominator. -- Ashley From dons at galois.com Fri Jul 31 20:01:07 2009 From: dons at galois.com (Don Stewart) Date: Fri Jul 31 19:44:17 2009 Subject: ANNOUNCE: The Haskell Platform 2009.2.0.2 Message-ID: <20090801000107.GM3854@whirlpool.galois.com> We're pleased to announce the third release of the Haskell Platform: a single, standard Haskell distribution for everyone. The specification, along with installers (including Windows and Unix installers for a full Haskell environment) are available. Download the Haskell Platform 2009.2.0.2: http://hackage.haskell.org/platform/ The Haskell Platform is a single, standard Haskell distribution for every system, in the form of a blessed library and tool suite for Haskell distilled from the thousands of libraries on Hackage, along with installers for a wide variety of systems. It saves developers work picking and choosing the best Haskell libraries and tools to use for a task. When you install the Haskell Platform, you get the latest stable compiler, an expanded set of core libraries, additional development tools, and cabal-install ? so you can download anything else you need from Hackage. What you get: http://hackage.haskell.org/platform/contents.html With regular time-based releases, we expect the platform will grow into a rich, indispensable development environment for all Haskell projects. Since the first release, there have been over 100,000 downloads of the installers. Thanks! -- The Platform Infrastructure Team