From johan.tibell at gmail.com Thu Aug 2 01:23:34 2012 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed, 1 Aug 2012 16:23:34 -0700 Subject: Small problem in containers-0.5.0.0 docs In-Reply-To: References: Message-ID: Fixed. Thanks for the bug report! In the future you can file reports at https://github.com/haskell/containers/issues to make sure I don't forget about them! :) On Wed, Aug 1, 2012 at 6:30 AM, Christoph Breitkopf wrote: > Hello, > > the haddoc sources refer to the strict/lazy modules using single quotes, > which does not work, as is is interpreted as a type reference > (.../Data-Map.html#t:Strict). Replacing the single quotes by double quotes > for a module reference fixes this. (I just had the same problem in > IntervalMap). > > I spotted the problem in Data.Map, but it's probably also present in other > modules. > > Regards, > > Chris From dsf at seereason.com Thu Aug 9 18:28:31 2012 From: dsf at seereason.com (David Fox) Date: Thu, 9 Aug 2012 09:28:31 -0700 Subject: System.Process.ByteString.readProcess, readProcessWithExitCode Message-ID: Attached is a module containing ByteString analogs of two functions from System.Process: readProcess and readProcessWithExitCode. I use these a lot and would love to see them incorporated into a standard library, though I'm not sure which one. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ByteString.hs Type: application/octet-stream Size: 3877 bytes Desc: not available URL: From dsf at seereason.com Thu Aug 9 20:33:33 2012 From: dsf at seereason.com (David Fox) Date: Thu, 9 Aug 2012 11:33:33 -0700 Subject: System.Process.ByteString.readProcess, readProcessWithExitCode In-Reply-To: References: Message-ID: On Thu, Aug 9, 2012 at 9:28 AM, David Fox wrote: > Attached is a module containing ByteString analogs of two functions from > System.Process: readProcess and readProcessWithExitCode. I use these a lot > and would love to see them incorporated into a standard library, though I'm > not sure which one. Sorry, didn't know attachments were excluded. The two functions are available in the Unixutils library: http://hackage.haskell.org/packages/archive/Unixutils/1.50/doc/html/System-Unix-Process.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwiegley at gmail.com Thu Aug 9 19:19:20 2012 From: jwiegley at gmail.com (John Wiegley) Date: Thu, 09 Aug 2012 12:19:20 -0500 Subject: System.Process.ByteString.readProcess, readProcessWithExitCode References: Message-ID: >>>>> David Fox writes: > Attached is a module containing ByteString analogs of two functions from > System.Process: readProcess and readProcessWithExitCode. ?I use these a lot > and would love to see them incorporated into a standard library, though I'm > not sure which one. I agree. I wrote my own version of readProcessWithExitCode a while back as well. John From v.dijk.bas at gmail.com Fri Aug 10 09:01:25 2012 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Fri, 10 Aug 2012 09:01:25 +0200 Subject: System.Process.ByteString.readProcess, readProcessWithExitCode In-Reply-To: References: Message-ID: On 9 August 2012 20:33, David Fox wrote: > On Thu, Aug 9, 2012 at 9:28 AM, David Fox wrote: >> >> Attached is a module containing ByteString analogs of two functions from >> System.Process: readProcess and readProcessWithExitCode. I use these a lot >> and would love to see them incorporated into a standard library, though I'm >> not sure which one. > > > Sorry, didn't know attachments were excluded. The two functions are > available in the Unixutils library: > http://hackage.haskell.org/packages/archive/Unixutils/1.50/doc/html/System-Unix-Process.html Some time ago I fixed some asynchronous exception bugs in those functions. Take a look at the current implementation: https://github.com/ghc/packages-process/blob/master/System/Process.hs#L392 You might want to incorporate these changes into your library. Cheers, Bas From dsf at seereason.com Fri Aug 10 21:13:41 2012 From: dsf at seereason.com (David Fox) Date: Fri, 10 Aug 2012 12:13:41 -0700 Subject: System.Process.ByteString.readProcess, readProcessWithExitCode In-Reply-To: References: Message-ID: On Fri, Aug 10, 2012 at 12:01 AM, Bas van Dijk wrote: > On 9 August 2012 20:33, David Fox wrote: > > On Thu, Aug 9, 2012 at 9:28 AM, David Fox wrote: > >> > >> Attached is a module containing ByteString analogs of two functions from > >> System.Process: readProcess and readProcessWithExitCode. I use these a > lot > >> and would love to see them incorporated into a standard library, though > I'm > >> not sure which one. > > > > > > Sorry, didn't know attachments were excluded. The two functions are > > available in the Unixutils library: > > > http://hackage.haskell.org/packages/archive/Unixutils/1.50/doc/html/System-Unix-Process.html > > Some time ago I fixed some asynchronous exception bugs in those > functions. Take a look at the current implementation: > > https://github.com/ghc/packages-process/blob/master/System/Process.hs#L392 > > You might want to incorporate these changes into your library. > It looks like this will have to wait for bytestring 0.10, which has NFData instances. I guess there are ways to hack this... -------------- next part -------------- An HTML attachment was scrubbed... URL: From lazar6 at illinois.edu Sun Aug 12 22:53:10 2012 From: lazar6 at illinois.edu (David Lazar) Date: Sun, 12 Aug 2012 20:53:10 +0000 (UTC) Subject: System.Process.ByteString.readProcess, readProcessWithExitCode References: Message-ID: David Fox seereason.com> writes: > Attached is a module containing ByteString analogs of two functions from > System.Process: readProcess and readProcessWithExitCode. I use these a lot > and would love to see them incorporated into a standard library, though I'm > not sure which one. I have the process-extras library on Hackage which contains readProcessWithExitCode variants for ByteString and Text. http://hackage.haskell.org/package/process-extras I'd be happy to apply patches which add readProcess and make other improvements :-). Cheers, David From ekmett at gmail.com Mon Aug 13 10:16:11 2012 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 13 Aug 2012 04:16:11 -0400 Subject: PolyKinds, Control.Category and GHC 7.6.1 Message-ID: Would it be possible to add something like {-# LANGUAGE CPP #-} #if defined(__GLASGOW_HASKELL__) && __GLASGOW_HASKELL__ >= 704 {-# LANGUAGE PolyKinds #-} #endif to the top of Control.Category before the 7.6.1 final release? Control.Category.Category is pretty much the only type in base that directly benefits from PolyKinds without any code changes, but without enabling the extension there nobody can define categories for kinds other than *, and most interesting categories actually have more exotic kinds. I only noticed that it wasn't there in the release candidate just now. -Edward Kmett -------------- next part -------------- An HTML attachment was scrubbed... URL: From danburton.email at gmail.com Mon Aug 13 15:55:39 2012 From: danburton.email at gmail.com (Dan Burton) Date: Mon, 13 Aug 2012 07:55:39 -0600 Subject: PolyKinds, Control.Category and GHC 7.6.1 In-Reply-To: References: Message-ID: > > Control.Category.Category is pretty much the only type in base that > directly benefits from PolyKinds without any code changes, but without > enabling the extension there nobody can define categories for kinds other > than *, and most interesting categories actually have more exotic kinds. What, precisely, is the benefit of turning on PolyKinds for that file without changing the code? If we're cpp'ing it in, then are there further benefits that we could also reap by cpp'ing some code changes? -- Dan Burton -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Mon Aug 13 16:12:26 2012 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 13 Aug 2012 10:12:26 -0400 Subject: PolyKinds, Control.Category and GHC 7.6.1 In-Reply-To: References: Message-ID: On Mon, Aug 13, 2012 at 9:55 AM, Dan Burton wrote: > Control.Category.Category is pretty much the only type in base that >> directly benefits from PolyKinds without any code changes, but without >> enabling the extension there nobody can define categories for kinds other >> than *, and most interesting categories actually have more exotic >> kinds. > > > What, precisely, is the benefit of turning on PolyKinds for that file > without changing the code? If we're cpp'ing it in, then are there further > benefits that we could also reap by cpp'ing some code changes? > The benefit is that the kind of Category changes to Category :: (x -> x -> *) -> Constraint This means I can do things like make data Dict p where Dict :: p => Dict p newtype a |- b = Sub (a => Dict b) and then (|-) :: Constraint -> Constraint -> * is a valid candidate to become a Category. Moreover, PolyKinds + DataKinds finally enable us to write product and sum categories, make categories for natural transformations, and generally finally put Category to work. These were all disallowed by the previous simpler kind. No code changes need be applied beyond permitting the type of Category to generalize and existing code continues to work. This change actually could have been applied in 7.4.1. -Edward Kmett -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Mon Aug 13 19:13:08 2012 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 13 Aug 2012 19:13:08 +0200 (CEST) Subject: Proposal: Add hasBitSize to Data.Bits.Bits In-Reply-To: References: <50141A01.2010707@ifi.lmu.de>

Message-ID: On Sun, 29 Jul 2012, Thomas Schilling wrote: > On 29 July 2012 15:37, Thomas DuBuisson wrote: >> >> That is a great point. Most my uses of 'bitSize' are monomorphic and >> Maybe would just be silly. OTOH, I'd be more than happy to fix up any >> polymorphic code to include a new BitSize constraint. > > To make sure I understand this correctly: > > The current problem is that bitSize is a partial function *depending > on the type* of its argument (currently it always returns _|_ for > Integer, and is total for any other type). That does indeed seem like > a Bad Idea. > > You propose to: > > 1. Remove "bitSize" from the Bits class. > 2. Add a new class BitSize which only contains the "bitSize" method. > Integer would not be an instance of this class. +1 From ekmett at gmail.com Mon Aug 13 23:38:40 2012 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 13 Aug 2012 17:38:40 -0400 Subject: Proposal: Add hasBitSize to Data.Bits.Bits In-Reply-To: References: <50141A01.2010707@ifi.lmu.de>

Message-ID: On Sun, Jul 29, 2012 at 12:38 PM, Antoine Latter wrote: > On Sun, Jul 29, 2012 at 11:37 AM, Antoine Latter > wrote: > > > > The downside to this proposal is that the requester (Edward) actually > > wants a function of type "a -> Maybe Int", so his polymorphic function > > can handle both infinite bit-types and finite bit-types. > > > > With the new class, Edward could write: > > > > class BitTraversable i where > > traverseBits :: > > > > instance (BitSize i) => BitTraversable i where > > traverseBits = > > > > instance BitTraversable Integer where > > traverseBits = > > > > I should add that this approach looks like it would require > OverlappingInstances. Correct. This is not a viable solution for the problem, also it precludes the existance of support for someone else's Natural number type, etc. Every type that is currently an instance of Bits is either of a fixed size or potentially infinite. Changing bitSize to return a Maybe a works. Making a separate BitSize class simply forces me to do exactly what I'm doing right now, which is ignore it and manually probe. I'm a strong -1 vote to any solution that splits BitSize out into a separate class. -Edward -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Mon Aug 13 23:48:05 2012 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 13 Aug 2012 23:48:05 +0200 (CEST) Subject: Proposal: Add hasBitSize to Data.Bits.Bits In-Reply-To: References: <50141A01.2010707@ifi.lmu.de>

Message-ID: On Mon, 13 Aug 2012, Edward Kmett wrote: > Correct. This is not a viable solution for the problem, also it precludes the existance of support for > someone else's Natural number type, etc. > > Every type that is currently an instance of Bits is either of a fixed size or potentially infinite. > > Changing bitSize to return a Maybe a works. Making a separate BitSize class simply forces me to do exactly > what I'm doing right now, which is ignore it and manually probe.? How about two versions of 'bitSize' - one with Maybe return type in the Bits class and one without Maybe in a FixedBitSize subclass? From mark.lentczner at gmail.com Tue Aug 14 00:06:01 2012 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Mon, 13 Aug 2012 18:06:01 -0400 Subject: gearing up for 2012.4.0.0 Message-ID: It's that time again.... time to get cooking on another tasty Haskell Platform release! Here's my updated timeline for 2012.4.0.0, target: *November 12th, 2012* - *August 20th, 2012* - Call for proposals for additions and changes - *September 17th, 2012* - Call for proposals ends (no more proposals considered) - *October 1st, 2012* - Proposals decided, Initial version list - *October 15th, 2012* - First candidates - *October 29th, 2012* - Open issues resolved, Second candidates - *November 5th, 2012* - Final release candidates *If you are maintainer of a library in the platform:* Please start thinking about which version of your library should be in the release. If it will require coordination with versions of other libraries in the platform, now is the time to start coordinating. In mid-september, we will need to hear from the maintainers which version should be included: *I will not automatically bump to the latest version on Hackage for this release.* * * *If you are a maintainer of a library that you'd like to be in the platform: * Now is the time to get a clean version on Hackage, and then put together a proposal for the haskell-platform list. Please see the process for Adding Packages . *If you are part of the reviewing process:* Traditionally, proposals have been accompanied by lengthly discussions, often resulting in deep API design confabs. As we are approaching a release, I'd like to ask all to consider making this round more succinct if at all possible. In particular, it would be great if proposals were keyed to specific revisions of a library to be considered. If consensus is that something needs to be changed before inclusion - it would be best if maintainers took that input into account, turned another library version and placed that up for consideration. Please note the schedule: I'm going to hold October 1st firm. *If you are GHC Central: *I couldn't find a timeline for 7.6. Will that have hit a stable release by October 1st, or should we be planning on shipping 7.4.2 (which I think would be fine.) *If you are a packager or builder of HP releases: *Please review the trac ticket list . Please edit tickets to reflect reality: Close things that are fixed or won't ever be done. Edit descriptions with more information if you have it. But most importantly, please assign milestones correctly: If you are going to fix something this time - put it in the 2012.4.0.0 milestone. If it is for the future, put it in Blue Sky. - Mark "mzero" Lentczner, Chef de la Release -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Tue Aug 14 00:08:53 2012 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 13 Aug 2012 18:08:53 -0400 Subject: Proposal: Add hasBitSize to Data.Bits.Bits In-Reply-To: References: <50141A01.2010707@ifi.lmu.de>

Message-ID: That would work perfectly. Sent from my iPhone On Aug 13, 2012, at 5:48 PM, Henning Thielemann wrote: > > On Mon, 13 Aug 2012, Edward Kmett wrote: > >> Correct. This is not a viable solution for the problem, also it precludes the existance of support for >> someone else's Natural number type, etc. >> Every type that is currently an instance of Bits is either of a fixed size or potentially infinite. >> Changing bitSize to return a Maybe a works. Making a separate BitSize class simply forces me to do exactly >> what I'm doing right now, which is ignore it and manually probe. > > How about two versions of 'bitSize' - one with Maybe return type in the Bits class and one without Maybe in a FixedBitSize subclass? > From johan.tibell at gmail.com Tue Aug 14 00:13:38 2012 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 13 Aug 2012 15:13:38 -0700 Subject: Proposal: Add hasBitSize to Data.Bits.Bits In-Reply-To: References: <50141A01.2010707@ifi.lmu.de>

Message-ID: On Mon, Aug 13, 2012 at 2:48 PM, Henning Thielemann wrote: > How about two versions of 'bitSize' - one with Maybe return type in the Bits > class and one without Maybe in a FixedBitSize subclass? Is this worth breaking existing users of bitSize over? If anything it seems more worthwhile to throw out Integer from the Bits class and declare Bits to be for fixed sized entities. From lemming at henning-thielemann.de Tue Aug 14 00:19:36 2012 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 14 Aug 2012 00:19:36 +0200 (CEST) Subject: Proposal: Add hasBitSize to Data.Bits.Bits In-Reply-To: References: <50141A01.2010707@ifi.lmu.de>

Message-ID: On Mon, 13 Aug 2012, Johan Tibell wrote: > On Mon, Aug 13, 2012 at 2:48 PM, Henning Thielemann > wrote: >> How about two versions of 'bitSize' - one with Maybe return type in the Bits >> class and one without Maybe in a FixedBitSize subclass? > > Is this worth breaking existing users of bitSize over? If the method of 'FixedBitSize' is named 'bitSize' then only the type signature will be affected (FixedBitSize constraint instead of Bits). Although I don't know whether this is a good solution. > If anything it seems more worthwhile to throw out Integer from the Bits > class and declare Bits to be for fixed sized entities. From johan.tibell at gmail.com Tue Aug 14 00:21:56 2012 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 13 Aug 2012 15:21:56 -0700 Subject: Proposal: Add hasBitSize to Data.Bits.Bits In-Reply-To: References: <50141A01.2010707@ifi.lmu.de>

Message-ID: On Mon, Aug 13, 2012 at 3:19 PM, Henning Thielemann wrote: > > On Mon, 13 Aug 2012, Johan Tibell wrote: > >> On Mon, Aug 13, 2012 at 2:48 PM, Henning Thielemann >> wrote: >>> >>> How about two versions of 'bitSize' - one with Maybe return type in the >>> Bits >>> class and one without Maybe in a FixedBitSize subclass? >> >> >> Is this worth breaking existing users of bitSize over? > > > If the method of 'FixedBitSize' is named 'bitSize' then only the type > signature will be affected (FixedBitSize constraint instead of Bits). > Although I don't know whether this is a good solution. Imports will have to be modified as well if Bits keeps the name 'bitSize' for its method. In general these kind of breakages has been very painful in the past. Most libraries need to support the last two or three released versions of GHC (and thus base) so breaking changes like this are likely to result in lots of #ifdefs in client code to paper over the differences. Perhaps I'm getting old and cranky but I more in the never-break-anything camp than I used to be. -- Johan From lemming at henning-thielemann.de Tue Aug 14 00:26:49 2012 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 14 Aug 2012 00:26:49 +0200 (CEST) Subject: Proposal: Add hasBitSize to Data.Bits.Bits In-Reply-To: References: <50141A01.2010707@ifi.lmu.de>

Message-ID: On Mon, 13 Aug 2012, Johan Tibell wrote: > On Mon, Aug 13, 2012 at 3:19 PM, Henning Thielemann wrote: >> >> If the method of 'FixedBitSize' is named 'bitSize' then only the type >> signature will be affected (FixedBitSize constraint instead of Bits). >> Although I don't know whether this is a good solution. > > Imports will have to be modified as well if Bits keeps the name > 'bitSize' for its method. > > In general these kind of breakages has been very painful in the past. > Most libraries need to support the last two or three released versions > of GHC (and thus base) so breaking changes like this are likely to > result in lots of #ifdefs in client code to paper over the > differences. That's true. How about keeping 'bitSize' as it is, maybe deprecate it in the future, add maybeBitSize to Bits class and add a new class FixedBitSize with method fixedBitSize? From johan.tibell at gmail.com Tue Aug 14 00:41:35 2012 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 13 Aug 2012 15:41:35 -0700 Subject: Proposal: Add hasBitSize to Data.Bits.Bits In-Reply-To: References: <50141A01.2010707@ifi.lmu.de>

Message-ID: On Mon, Aug 13, 2012 at 3:26 PM, Henning Thielemann wrote: > > On Mon, 13 Aug 2012, Johan Tibell wrote: > >> On Mon, Aug 13, 2012 at 3:19 PM, Henning Thielemann >> wrote: >>> >>> >>> If the method of 'FixedBitSize' is named 'bitSize' then only the type >>> signature will be affected (FixedBitSize constraint instead of Bits). >>> Although I don't know whether this is a good solution. >> >> >> Imports will have to be modified as well if Bits keeps the name >> 'bitSize' for its method. >> >> In general these kind of breakages has been very painful in the past. >> Most libraries need to support the last two or three released versions >> of GHC (and thus base) so breaking changes like this are likely to >> result in lots of #ifdefs in client code to paper over the >> differences. > > > That's true. How about keeping 'bitSize' as it is, maybe deprecate it in the > future, add maybeBitSize to Bits class and add a new class FixedBitSize with > method fixedBitSize? This sounds more reasonably to me. I don't particularly need a fixedBitSize method, but if people have uses for it go ahead. From ekmett at gmail.com Tue Aug 14 00:42:54 2012 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 13 Aug 2012 18:42:54 -0400 Subject: Proposal: Add hasBitSize to Data.Bits.Bits In-Reply-To: References: <50141A01.2010707@ifi.lmu.de>

Message-ID: <0C6F0EF7-1A9F-4E4D-A49F-E0D2A4B72FD6@gmail.com> Throwing Integer out of Bits seems more prone to induce breakage than providing a more accurate type for bitSize -- I know at least one of my modules for working with boolean rings would have be scrapped. It is also likely to force users who wanted the bit operations they already had on Integer to create wonky local instances to get back behavior the previously had available. Given my druthers at this point I'd go for: Making a subclass to move the existing bitSize to, replete with a default definition. class Bits b => FiniteBits b where bitSize :: b -> Int bitSize = fromJust . perhapsBitSize and adding the perhapsBitSize Lennart suggested to BitSize to replace the moved bitSize: class Bits b where perhapsBitSize :: b -> Maybe Int ... Then code that only works for finite cases can use bitSize, code that already worked with infinite cases that never touched bitSize can continue to work, existing users that called bitSize but could only handle finite cases can change to FiniteBits and doesn't need to take a performance hit or fiddling with the Just constructor, and code that can work for the infinite case if it didn't crap out with bottom can safely upgrade to perhapsBitSize. I am not wedded to the perhapsBitSize name. I am wedded to not losing existing functionality unnecessarily, however. Sent from my iPhone On Aug 13, 2012, at 6:13 PM, Johan Tibell wrote: > On Mon, Aug 13, 2012 at 2:48 PM, Henning Thielemann > wrote: >> How about two versions of 'bitSize' - one with Maybe return type in the Bits >> class and one without Maybe in a FixedBitSize subclass? > > Is this worth breaking existing users of bitSize over? If anything it > seems more worthwhile to throw out Integer from the Bits class and > declare Bits to be for fixed sized entities. From ekmett at gmail.com Tue Aug 14 00:44:13 2012 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 13 Aug 2012 18:44:13 -0400 Subject: Proposal: Add hasBitSize to Data.Bits.Bits In-Reply-To: References: <50141A01.2010707@ifi.lmu.de>

Message-ID: <0492FCB7-3062-449E-B612-109A591B67CF@gmail.com> I'd be okay with this version of things as well. Sent from my iPhone On Aug 13, 2012, at 6:26 PM, Henning Thielemann wrote: > > On Mon, 13 Aug 2012, Johan Tibell wrote: > >> On Mon, Aug 13, 2012 at 3:19 PM, Henning Thielemann wrote: >>> >>> If the method of 'FixedBitSize' is named 'bitSize' then only the type >>> signature will be affected (FixedBitSize constraint instead of Bits). >>> Although I don't know whether this is a good solution. >> >> Imports will have to be modified as well if Bits keeps the name >> 'bitSize' for its method. >> >> In general these kind of breakages has been very painful in the past. >> Most libraries need to support the last two or three released versions >> of GHC (and thus base) so breaking changes like this are likely to >> result in lots of #ifdefs in client code to paper over the >> differences. > > That's true. How about keeping 'bitSize' as it is, maybe deprecate it in the future, add maybeBitSize to Bits class and add a new class FixedBitSize with method fixedBitSize? From thomas.dubuisson at gmail.com Tue Aug 14 00:51:37 2012 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Mon, 13 Aug 2012 15:51:37 -0700 Subject: Proposal: Add hasBitSize to Data.Bits.Bits In-Reply-To: <0C6F0EF7-1A9F-4E4D-A49F-E0D2A4B72FD6@gmail.com> References: <50141A01.2010707@ifi.lmu.de>

<0C6F0EF7-1A9F-4E4D-A49F-E0D2A4B72FD6@gmail.com> Message-ID: On Mon, Aug 13, 2012 at 3:42 PM, Edward Kmett wrote: > Throwing Integer out of Bits seems more prone to induce breakage than providing a more accurate type for bitSize -- I know at least one of my modules for working with boolean rings would have be scrapped. > > It is also likely to force users who wanted the bit operations they already had on Integer to create wonky local instances to get back behavior the previously had available. > > Given my druthers at this point I'd go for: > > Making a subclass to move the existing bitSize to, replete with a default definition. > > class Bits b => FiniteBits b where > bitSize :: b -> Int > bitSize = fromJust . perhapsBitSize > > and adding the perhapsBitSize Lennart suggested to BitSize to replace the moved bitSize: > > class Bits b where > perhapsBitSize :: b -> Maybe Int > ... I know I've been quite after stirring up some of this discussion. In general I am happy with this suggestion from Edward (+1) and am willing to fix up any breakage in my libraries, though I feel like much of this debate is due to insufficient type class machinery in the language that we should discuss some day. Thomas > > Then code that only works for finite cases can use bitSize, code that already worked with infinite cases that never touched bitSize can continue to work, existing users that called bitSize but could only handle finite cases can change to FiniteBits and doesn't need to take a performance hit or fiddling with the Just constructor, and code that can work for the infinite case if it didn't crap out with bottom can safely upgrade to perhapsBitSize. > > I am not wedded to the perhapsBitSize name. I am wedded to not losing existing functionality unnecessarily, however. > > Sent from my iPhone > > On Aug 13, 2012, at 6:13 PM, Johan Tibell wrote: > >> On Mon, Aug 13, 2012 at 2:48 PM, Henning Thielemann >> wrote: >>> How about two versions of 'bitSize' - one with Maybe return type in the Bits >>> class and one without Maybe in a FixedBitSize subclass? >> >> Is this worth breaking existing users of bitSize over? If anything it >> seems more worthwhile to throw out Integer from the Bits class and >> declare Bits to be for fixed sized entities. From johan.tibell at gmail.com Tue Aug 14 01:08:39 2012 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 13 Aug 2012 16:08:39 -0700 Subject: Proposal: Add hasBitSize to Data.Bits.Bits In-Reply-To: <0C6F0EF7-1A9F-4E4D-A49F-E0D2A4B72FD6@gmail.com> References: <50141A01.2010707@ifi.lmu.de>

<0C6F0EF7-1A9F-4E4D-A49F-E0D2A4B72FD6@gmail.com> Message-ID: On Mon, Aug 13, 2012 at 3:42 PM, Edward Kmett wrote: > Then code that only works for finite cases can use bitSize, code that already worked with infinite cases that never touched bitSize can continue to work, existing users that called bitSize but could only handle finite cases can change to FiniteBits and doesn't need to take a performance hit or fiddling with the Just constructor, and code that can work for the infinite case if it didn't crap out with bottom can safely upgrade to perhapsBitSize. This will still break client code though. The #ifdefs would then have to go in the import lists instead. I like Lennart's suggestion to deprecate 'bitSize' but not remove it. From illissius at gmail.com Tue Aug 14 02:15:12 2012 From: illissius at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Tue, 14 Aug 2012 02:15:12 +0200 Subject: PolyKinds, Control.Category and GHC 7.6.1 In-Reply-To: References: Message-ID: On Mon, Aug 13, 2012 at 10:16 AM, Edward Kmett wrote: > Would it be possible to add something like > > {-# LANGUAGE CPP #-} > #if defined(__GLASGOW_HASKELL__) && __GLASGOW_HASKELL__ >= 704 > {-# LANGUAGE PolyKinds #-} > #endif > > to the top of Control.Category before the 7.6.1 final release? > > Control.Category.Category is pretty much the only type in base that directly > benefits from PolyKinds without any code changes, but without enabling the > extension there nobody can define categories for kinds other than *, and > most interesting categories actually have more exotic kinds. > > I only noticed that it wasn't there in the release candidate just now. > > -Edward Kmett +1, this would be nice. > This change actually could have been applied in 7.4.1. FWIW PolyKinds in 7.4 is rough, and I had experiences where enabling it led to compile failures in downstream modules, so this wouldn't necessarily have been painless. Hopefully with 7.6 it will be. -- Your ship was destroyed in a monadic eruption. From amindfv at gmail.com Tue Aug 14 04:31:19 2012 From: amindfv at gmail.com (Tom Murphy) Date: Mon, 13 Aug 2012 22:31:19 -0400 Subject: maybeRead in base Message-ID: It would be great to have maybeRead in base in time for the next Haskell Platform release. There's been talk about including it several times, but it's remained as a utility function in other libraries (Network.CGI, for example, if I'm remembering right). Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From sol at typeful.net Tue Aug 14 08:54:13 2012 From: sol at typeful.net (Simon Hengel) Date: Tue, 14 Aug 2012 08:54:13 +0200 Subject: maybeRead in base In-Reply-To: References: Message-ID: <20120814065413.GB2742@x200> On Mon, Aug 13, 2012 at 10:31:19PM -0400, Tom Murphy wrote: > It would be great to have maybeRead in base in time for the next Haskell > Platform release. There's been talk about including it several times, but > it's remained as a utility function in other libraries (Network.CGI, for > example, if I'm remembering right). It's in base-4.6.0.0, but it's called readMaybe (personally, I don't like that name, but I guess it's for consistency with readEither). Cheers, Simon From dmcgill9071 at gmail.com Tue Aug 14 11:32:19 2012 From: dmcgill9071 at gmail.com (David McGillicuddy) Date: Tue, 14 Aug 2012 10:32:19 +0100 Subject: maybeRead in base In-Reply-To: <20120814065413.GB2742@x200> References: <20120814065413.GB2742@x200> Message-ID: What about (.:)*? Just looking at Hayoo quickly, at least half a dozen libraries seem to have defined it and it's a permanent feature on lambdabot. *(.:) :: (c -> d) -> (a -> b -> c) -> a -> b -> d (.:) = (.) (.) (.) David On Tue, Aug 14, 2012 at 7:54 AM, Simon Hengel wrote: > On Mon, Aug 13, 2012 at 10:31:19PM -0400, Tom Murphy wrote: > > It would be great to have maybeRead in base in time for the next Haskell > > Platform release. There's been talk about including it several times, but > > it's remained as a utility function in other libraries (Network.CGI, for > > example, if I'm remembering right). > > It's in base-4.6.0.0, but it's called readMaybe (personally, I don't > like that name, but I guess it's for consistency with readEither). > > Cheers, > Simon > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Aug 14 13:14:19 2012 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue, 14 Aug 2012 11:14:19 +0000 Subject: PolyKinds, Control.Category and GHC 7.6.1 In-Reply-To: References:

Message-ID: <59543203684B2244980D7E4057D5FBC137971160@DB3EX14MBXC312.europe.corp.microsoft.com> | FWIW PolyKinds in 7.4 is rough, and I had experiences where enabling it | led to compile failures in downstream modules, so this wouldn't | necessarily have been painless. Hopefully with 7.6 it will be. PolyKinds is not an advertised feature of 7.4, so you should absolutely not rely on it working in 7.4. But it IS an advertised feature for 7.6 and should work flawlessly. (If not, yell.) Simon From bos at serpentine.com Tue Aug 14 19:27:38 2012 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue, 14 Aug 2012 10:27:38 -0700 Subject: gearing up for 2012.4.0.0 In-Reply-To: References: Message-ID: On Mon, Aug 13, 2012 at 3:06 PM, Mark Lentczner wrote: > > *If you are part of the reviewing process:* Traditionally, proposals have > been accompanied by lengthly discussions, often resulting in deep API > design confabs. > The discussion period for inclusion of vector in the HP has ended. I'd like to move that vector 0.9.1 be added to the next HP. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Tue Aug 14 20:02:15 2012 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 14 Aug 2012 14:02:15 -0400 Subject: gearing up for 2012.4.0.0 In-Reply-To: References: Message-ID: +1 On Tue, Aug 14, 2012 at 1:27 PM, Bryan O'Sullivan wrote: > On Mon, Aug 13, 2012 at 3:06 PM, Mark Lentczner wrote: > >> >> *If you are part of the reviewing process:* Traditionally, proposals >> have been accompanied by lengthly discussions, often resulting in deep API >> design confabs. >> > > The discussion period for inclusion of vector in the HP has ended. I'd > like to move that vector 0.9.1 be added to the next HP. > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwiegley at gmail.com Mon Aug 13 21:23:01 2012 From: jwiegley at gmail.com (John Wiegley) Date: Mon, 13 Aug 2012 14:23:01 -0500 Subject: System.Process.ByteString.readProcess, readProcessWithExitCode References:

Message-ID: >>>>> David Lazar writes: > I have the process-extras library on Hackage which contains > readProcessWithExitCode variants for ByteString and Text. How about adding the same function for the lazy variants? John From ekmett at gmail.com Wed Aug 15 02:41:43 2012 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 14 Aug 2012 20:41:43 -0400 Subject: gearing up for 2012.4.0.0 In-Reply-To: References: Message-ID: Lest I forget, we'll need to bump mtl to the 2.1.2 that is already on Hackage to work with changes to the Prelude. http://hdiff.luite.com/cgit/mtl/commit/?id=73be6cb23732ffb292412602b3b492fbc2a26f6a -Edward Kmett -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christian.Maeder at dfki.de Wed Aug 15 15:07:33 2012 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed, 15 Aug 2012 15:07:33 +0200 Subject: List-0.4.3 Message-ID: <502B9F15.1000208@dfki.de> Hi, The change in package List-0.4.3 cause hexpat to fail. (It works with List-0.4.2 without "mapMaybe") C. Resolving dependencies... Downloading hexpat-0.20.2... Configuring hexpat-0.20.2... Building hexpat-0.20.2... Preprocessing library hexpat-0.20.2... [ 1 of 12] Compiling Text.XML.Expat.Internal.IO ( Text/XML/Expat/Internal/IO.hs, dist/build/Text/XML/Expat/Internal/IO.o ) [ 2 of 12] Compiling Text.XML.Expat.SAX ( Text/XML/Expat/SAX.hs, dist/build/Text/XML/Expat/SAX.o ) [ 3 of 12] Compiling Text.XML.Expat.Internal.NodeClass ( Text/XML/Expat/Internal/NodeClass.hs, dist/build/Text/XML/Expat/Internal/NodeClass.o ) [ 4 of 12] Compiling Text.XML.Expat.Internal.Qualified ( Text/XML/Expat/Internal/Qualified.hs, dist/build/Text/XML/Expat/Internal/Qualified.o ) [ 5 of 12] Compiling Text.XML.Expat.Internal.Namespaced ( Text/XML/Expat/Internal/Namespaced.hs, dist/build/Text/XML/Expat/Internal/Namespaced.o ) [ 6 of 12] Compiling Text.XML.Expat.Tree ( Text/XML/Expat/Tree.hs, dist/build/Text/XML/Expat/Tree.o ) [ 7 of 12] Compiling Text.XML.Expat.Cursor ( Text/XML/Expat/Cursor.hs, dist/build/Text/XML/Expat/Cursor.o ) [ 8 of 12] Compiling Text.XML.Expat.Internal.DocumentClass ( Text/XML/Expat/Internal/DocumentClass.hs, dist/build/Text/XML/Expat/Internal/DocumentClass.o ) [ 9 of 12] Compiling Text.XML.Expat.Extended ( Text/XML/Expat/Extended.hs, dist/build/Text/XML/Expat/Extended.o ) Text/XML/Expat/Extended.hs:372:25: Ambiguous occurrence `mapMaybe' It could refer to either `Data.List.Class.mapMaybe', imported from `Data.List.Class' at Text/XML/Expat/Extended.hs:83:1-22 or `Data.Maybe.mapMaybe', imported from `Data.Maybe' at Text/XML/Expat/Extended.hs:84:1-17 cabal: Error: some packages failed to install: hexpat-0.20.2 failed during the building phase. The exception was: ExitFailure 1 From ekmett at gmail.com Wed Aug 15 19:02:39 2012 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 15 Aug 2012 13:02:39 -0400 Subject: maybeRead in base In-Reply-To: References: <20120814065413.GB2742@x200> Message-ID: I'm not a huge fan of (.:), but you insist on adding it, please generalize it to fmap.fmap. (.:) :: (Functor f, Functor g) => (a -> b) -> f (g a) -> f (g b) This subsumes the other use case. -Edward On Tue, Aug 14, 2012 at 5:32 AM, David McGillicuddy wrote: > What about (.:)*? Just looking at Hayoo quickly, at least half a dozen > libraries seem to have defined it and it's a permanent feature on lambdabot. > > *(.:) :: (c -> d) -> (a -> b -> c) -> a -> b -> d > (.:) = (.) (.) (.) > > David > > On Tue, Aug 14, 2012 at 7:54 AM, Simon Hengel wrote: > >> On Mon, Aug 13, 2012 at 10:31:19PM -0400, Tom Murphy wrote: >> > It would be great to have maybeRead in base in time for the next Haskell >> > Platform release. There's been talk about including it several times, >> but >> > it's remained as a utility function in other libraries (Network.CGI, for >> > example, if I'm remembering right). >> >> It's in base-4.6.0.0, but it's called readMaybe (personally, I don't >> like that name, but I guess it's for consistency with readEither). >> >> Cheers, >> Simon >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christian.Maeder at dfki.de Thu Aug 16 11:50:38 2012 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu, 16 Aug 2012 11:50:38 +0200 Subject: List-0.4.3 (and hexpat) In-Reply-To: References: <502B9F15.1000208@dfki.de> Message-ID: <502CC26E.8010103@dfki.de> Thanks for your prompt response and action! Am 15.08.2012 23:46, schrieb Yair Chuchem: > Hi Christian, > > Please try again now (after a cabal update). > I uploaded List-0.4.4 which removes mapMaybe, and then also uploaded > List-0.5.0 which re-adds it. > hexpat should now be using List-0.4.4 as it wants List < 0.5 > > I'll follow up with a few steps: > * Make myself a rule to test installing hexpat before I push updates to > List in future. > * Contact Stephen to change hexpat to not use unqualified open imports, > at least for List. His email was not in the package description. Christian > * Add docs to my package warning users that using it with unqualified > open imports may be more dangerous than usual (btw unqualified open > imports are always dangerous) because List exports functions which > generalize Prelude functions and shares their names by design. Similar > to how Control.Category exports "." and "id". > > Cheers & Happy coding, > Yair From twanvl at gmail.com Thu Aug 16 13:16:46 2012 From: twanvl at gmail.com (Twan van Laarhoven) Date: Thu, 16 Aug 2012 13:16:46 +0200 Subject: maybeRead in base In-Reply-To: References: <20120814065413.GB2742@x200>

Message-ID: <502CD69E.6080504@gmail.com> On 15/08/12 19:02, Edward Kmett wrote: > I'm not a huge fan of (.:), but you insist on adding it, please generalize it to > fmap.fmap. > > (.:) :: (Functor f, Functor g) => (a -> b) -> f (g a) -> f (g b) > > This subsumes the other use case. For the love of Categories, please don't go down this road. fmap is not the proper generalization of (.). Twan From ekmett at gmail.com Thu Aug 16 17:14:05 2012 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 16 Aug 2012 11:14:05 -0400 Subject: maybeRead in base In-Reply-To: <502CD69E.6080504@gmail.com> References: <20120814065413.GB2742@x200>

<502CD69E.6080504@gmail.com> Message-ID: This is part of why I'm not a fan of (.:) in the first place, but trying to generalize through Category doesn't offer anything here. Sent from my iPad On Aug 16, 2012, at 7:16 AM, Twan van Laarhoven wrote: > On 15/08/12 19:02, Edward Kmett wrote: >> I'm not a huge fan of (.:), but you insist on adding it, please generalize it to >> fmap.fmap. >> >> (.:) :: (Functor f, Functor g) => (a -> b) -> f (g a) -> f (g b) >> >> This subsumes the other use case. > > For the love of Categories, please don't go down this road. fmap is not the proper generalization of (.). > > > Twan > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries From v.dijk.bas at gmail.com Thu Aug 16 18:36:36 2012 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Thu, 16 Aug 2012 18:36:36 +0200 Subject: System.Process.ByteString.readProcess, readProcessWithExitCode In-Reply-To: References:

Message-ID: On 12 August 2012 22:53, David Lazar wrote: > I'd be happy to apply patches which add readProcess and make other > improvements :-). I made a pull request that fixes some asynchronous exception bugs and adds the System.Process.Text.Lazy module: https://github.com/davidlazar/process-extras/pull/1 Cheers, Bas From lazar6 at illinois.edu Fri Aug 17 02:21:33 2012 From: lazar6 at illinois.edu (David Lazar) Date: Thu, 16 Aug 2012 19:21:33 -0500 Subject: System.Process.ByteString.readProcess, readProcessWithExitCode In-Reply-To: References:

Message-ID: On Thu, Aug 16, 2012 at 11:36 AM, Bas van Dijk wrote: > On 12 August 2012 22:53, David Lazar wrote: >> I'd be happy to apply patches which add readProcess and make other >> improvements :-). > > I made a pull request that fixes some asynchronous exception bugs and > adds the System.Process.Text.Lazy module: > > https://github.com/davidlazar/process-extras/pull/1 Awesome. I've merged the pull request. I'll release a new version shortly. Cheers, David From dsf at seereason.com Fri Aug 17 02:31:07 2012 From: dsf at seereason.com (David Fox) Date: Thu, 16 Aug 2012 17:31:07 -0700 Subject: System.Process.ByteString.readProcess, readProcessWithExitCode In-Reply-To: References:

Message-ID: On Thu, Aug 16, 2012 at 9:36 AM, Bas van Dijk wrote: > On 12 August 2012 22:53, David Lazar wrote: > > I'd be happy to apply patches which add readProcess and make other > > improvements :-). > > I made a pull request that fixes some asynchronous exception bugs and > adds the System.Process.Text.Lazy module: > > https://github.com/davidlazar/process-extras/pull/1 Does this depend on bytestring >= 0.10? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Fri Aug 17 14:10:02 2012 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 17 Aug 2012 14:10:02 +0200 (CEST) Subject: addForeignPtrFinalizer - finalizers run in FIFO or LIFO order? Message-ID: The doc of base-4.5:Foreign.ForeignPtr.addForeignPtrFinalizer states: "This function adds a finalizer to the given foreign object. The finalizer will run before all other finalizers for the same object which have already been registered." I do addForeignPtrFinalizer finalize1 fp addForeignPtrFinalizer finalize2 fp and let the finalizers print something when they are started. I get the output: finalizer1 finalizer2 This indicates that the newly added finalizer is run _after_ the finalizers that are already registered. Is this a documentation bug or a bug in the base library? From lemming at henning-thielemann.de Fri Aug 17 17:34:05 2012 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 17 Aug 2012 17:34:05 +0200 (CEST) Subject: addForeignPtrFinalizer - finalizers run in FIFO or LIFO order? In-Reply-To: References: Message-ID: On Fri, 17 Aug 2012, Henning Thielemann wrote: > The doc of base-4.5:Foreign.ForeignPtr.addForeignPtrFinalizer states: > "This function adds a finalizer to the given foreign object. The finalizer > will run before all other finalizers for the same object which have already > been registered." > > > I do > > addForeignPtrFinalizer finalize1 fp > addForeignPtrFinalizer finalize2 fp > > and let the finalizers print something when they are started. > I get the output: > > finalizer1 > finalizer2 > > This indicates that the newly added finalizer is run _after_ the finalizers > that are already registered. Is this a documentation bug or a bug in the base > library? Hm, it seems to depend on the context. In some situations I get the correct (reversed) order finalizer2 finalizer1 and in others I get finalizer1 first and then finalizer2. Any hint what can change the order of finalizers? From lemming at henning-thielemann.de Fri Aug 17 18:32:14 2012 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 17 Aug 2012 18:32:14 +0200 (CEST) Subject: addForeignPtrFinalizer - finalizers run in FIFO or LIFO order? In-Reply-To: References:

Message-ID: On Fri, 17 Aug 2012, Henning Thielemann wrote: > On Fri, 17 Aug 2012, Henning Thielemann wrote: > >> The doc of base-4.5:Foreign.ForeignPtr.addForeignPtrFinalizer states: >> "This function adds a finalizer to the given foreign object. The >> finalizer will run before all other finalizers for the same object which >> have already been registered." >> >> >> I do >> >> addForeignPtrFinalizer finalize1 fp >> addForeignPtrFinalizer finalize2 fp >> >> and let the finalizers print something when they are started. >> I get the output: >> >> finalizer1 >> finalizer2 >> >> This indicates that the newly added finalizer is run _after_ the finalizers >> that are already registered. Is this a documentation bug or a bug in the >> base library? > > > Hm, it seems to depend on the context. In some situations I get the correct > (reversed) order > > finalizer2 > finalizer1 > > and in others I get finalizer1 first and then finalizer2. Any hint what can > change the order of finalizers? continuing my monologue ... It seems that a simple modification like turning a not directly related allocaBytes into a mallocBytes reverses the order from incorrect to correct (reversed). Maybe adding the finalizers is not the problem but running them. Maybe there are different ways to run the finalizers and allocaBytes causes an invalid execution of finalizers whereas mallocBytes leaves the correct way. From ezyang at MIT.EDU Fri Aug 17 22:06:44 2012 From: ezyang at MIT.EDU (Edward Z. Yang) Date: Fri, 17 Aug 2012 16:06:44 -0400 Subject: addForeignPtrFinalizer - finalizers run in FIFO or LIFO order? In-Reply-To: References: Message-ID: <1345233987-sup-6852@ezyang> No. 1 question: do you have a reproduceable test case of both behaviors? Edward Excerpts from Henning Thielemann's message of Fri Aug 17 08:10:02 -0400 2012: > > The doc of base-4.5:Foreign.ForeignPtr.addForeignPtrFinalizer states: > "This function adds a finalizer to the given foreign object. The > finalizer will run before all other finalizers for the same object which > have already been registered." > > > I do > > addForeignPtrFinalizer finalize1 fp > addForeignPtrFinalizer finalize2 fp > > and let the finalizers print something when they are started. > I get the output: > > finalizer1 > finalizer2 > > This indicates that the newly added finalizer is run _after_ the > finalizers that are already registered. Is this a documentation bug or a > bug in the base library? > From lemming at henning-thielemann.de Fri Aug 17 22:29:34 2012 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 17 Aug 2012 22:29:34 +0200 (CEST) Subject: addForeignPtrFinalizer - finalizers run in FIFO or LIFO order? In-Reply-To: <1345233987-sup-6852@ezyang> References: <1345233987-sup-6852@ezyang> Message-ID: On Fri, 17 Aug 2012, Edward Z. Yang wrote: > No. 1 question: do you have a reproduceable test case of both behaviors? Unfortunately I was not able to reduce it to a small test. Below a certain complexity the problem vanishes. Currently my example has many dependencies on external libraries (libav etc.) :-( Thus I hoped I could approach the problem from a different direction. If there are different ways to run the finalizers of a ForeignPtr then I could check them. I could not find something suspicious in base:GHC.ForeignPtr, though. From bertram.felgenhauer at googlemail.com Sat Aug 18 17:43:38 2012 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Sat, 18 Aug 2012 17:43:38 +0200 Subject: addForeignPtrFinalizer - finalizers run in FIFO or LIFO order? In-Reply-To: References: Message-ID: <20120818154338.GA5168@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Henning Thielemann wrote: > and let the finalizers print something when they are started. > I get the output: > > finalizer1 > finalizer2 Funny bug, I can reproduce it. (And it is a bug; the code in question violates a documented invariant.) What happens is, in essence, that the list of finalizers is reversed during garbage collection. See http://hackage.haskell.org/trac/ghc/ticket/7160 for an example program. Best regards, Bertram From lemming at henning-thielemann.de Sat Aug 18 18:10:14 2012 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 18 Aug 2012 18:10:14 +0200 (CEST) Subject: addForeignPtrFinalizer - finalizers run in FIFO or LIFO order? In-Reply-To: <20120818154338.GA5168@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> References: <20120818154338.GA5168@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Message-ID: Hi Bertram, On Sat, 18 Aug 2012, Bertram Felgenhauer wrote: > Henning Thielemann wrote: >> and let the finalizers print something when they are started. >> I get the output: >> >> finalizer1 >> finalizer2 > > Funny bug, I can reproduce it. (And it is a bug; the code in question > violates a documented invariant.) What happens is, in essence, that the > list of finalizers is reversed during garbage collection. > > See http://hackage.haskell.org/trac/ghc/ticket/7160 for an example > program. Thank you a lot for working out the example! It could have required ages for me to reduce my problem to such a compact example. From mark.lentczner at gmail.com Tue Aug 21 15:43:39 2012 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Tue, 21 Aug 2012 06:43:39 -0700 Subject: HP 2012.4.0.0 -- Call for Proposals Message-ID: While proposals for changes to Haskell Platform can be made at any time, this call is for proposals that would like to land in the 2012.4.0.0 release. The 2012.4.0.0 is scheduled for November 12th, 2012. In order for a proposal to made it in that release, it needs to meet the following timeline: - *August 20th, 2012* - Call for proposals for additions and changes - *September 17th, 2012* - Call for proposals ends (no more proposals considered) - *October 1st, 2012* - Proposals decided, Initial version list *If you are a maintainer of a library that you'd like to be in the platform: * Now is the time to get a clean version on Hackage, and then put together a proposal for the haskell-platform list. Please see the process for Adding Packages . *Outstanding work:* - There is a proposal to include vector-0.9.1 in the platform - There is a ticket to consider including OpenGLRaw ? Ticket #167 - There are tickets to consider removing OpenGL and GLUT ? Ticket #57, Ticket #58 - There is a ticket about binary being in the platform without being part of it ? Ticket #191 - There is a ticket about needing hscolour to build the platform, but it isn't part of it ? Ticket #160 Please not that none of the tickets is a proposal before the list yet. If the maintainer of those libraries, or someone else, want to propose a change based on those tickets, now is the time to do so. In any event, I will close those tickets on September 17th. *If you are part of the reviewing process:* Traditionally, proposals have been accompanied by lengthly discussions, often resulting in deep API design confabs. As we are approaching a release, I'd like to ask all to consider making this round more succinct if at all possible. In particular, it would be great if proposals were keyed to specific revisions of a library to be considered. If consensus is that something needs to be changed before inclusion - it would be best if maintainers took that input into account, turned another library version and placed that up for consideration. Please note the schedule: I'm going to hold October 1st firm. ? Mark "proposed in a restaurant in front of friends" Lentczner -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Tue Aug 21 17:32:49 2012 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 21 Aug 2012 16:32:49 +0100 Subject: HP 2012.4.0.0 -- Call for Proposals In-Reply-To: References: Message-ID: <5033AA21.8070703@gmail.com> There's also a proposal (by me) to include the async package: http://trac.haskell.org/haskell-platform/wiki/Proposals/async The deadlines have now expired. During the discussion several people were positive about the package, however I don't think anyone expressed an opinion specifically on whether the package should be in the platform. I'm not sure how to interpret that result - at the least, it suggests a certain lack of enthusiasm. I'm still keen to see the package go in, mainly because when you start doing concurrent programming you quite quickly run into the need for some way to return results from threads, and then you need error handling. Then you start to need a way to wait for results from multiple threads with error handling... people build these things themselves, but in fact it's quite tricky with the basic Control.Concurrent API to do it right. The async package provides a well though-out API for that essential functionality, in a way that composes nicely. It's a very small package, but it should be a part of our standard vocabulary in my opinion. We should have it if only for the cool one-liners you can write with mapConcurrently :: Traversable t => (a -> IO b) -> t a -> IO (t b) :-) On the other hand, given that nobody else argued for it to be in the platform, a reasonable decision would be "wait and see"; I'd be fine with that too. Cheers, Simon On 21/08/2012 14:43, Mark Lentczner wrote: > While proposals for changes to Haskell Platform can be made at any time, > this call is for proposals that would like to land in the 2012.4.0.0 > release. > > The 2012.4.0.0 is scheduled for November 12th, 2012. In order for a > proposal to made it in that release, it needs to meet the following > timeline: > > * *August 20th, 2012* - Call for proposals for additions and changes > * *September 17th, 2012* - Call for proposals ends (no more proposals > considered) > * *October 1st, 2012* - Proposals decided, Initial version list > > *If you are a maintainer of a library that you'd like to be in the > platform:* Now is the time to get a clean version on Hackage, and then > put together a proposal for the haskell-platform list. Please see the > process for Adding Packages > . > > *Outstanding work:* > > * There is a proposal to include vector-0.9.1 in the platform > * There is a ticket to consider including OpenGLRaw ? Ticket #167 > > * There are tickets to consider removing OpenGL and GLUT ? Ticket #57 > , Ticket #58 > > * There is a ticket about binary being in the platform without being > part of it ? Ticket #191 > > * There is a ticket about needing hscolour to build the platform, but > it isn't part of it ? Ticket #160 > > > Please not that none of the tickets is a proposal before the list yet. > If the maintainer of those libraries, or someone else, want to propose a > change based on those tickets, now is the time to do so. In any event, I > will close those tickets on September 17th. > > *If you are part of the reviewing process:* Traditionally, proposals > have been accompanied by lengthly discussions, often resulting in deep > API design confabs. As we are approaching a release, I'd like to ask all > to consider making this round more succinct if at all possible. In > particular, it would be great if proposals were keyed to specific > revisions of a library to be considered. If consensus is that something > needs to be changed before inclusion - it would be best if maintainers > took that input into account, turned another library version and placed > that up for consideration. Please note the schedule: I'm going to hold > October 1st firm. > > ? Mark "proposed in a restaurant in front of friends" Lentczner > > > _______________________________________________ > Haskell-platform mailing list > Haskell-platform at projects.haskell.org > http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform > From bos at serpentine.com Tue Aug 21 17:54:47 2012 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue, 21 Aug 2012 08:54:47 -0700 Subject: HP 2012.4.0.0 -- Call for Proposals In-Reply-To: <5033AA21.8070703@gmail.com> References: <5033AA21.8070703@gmail.com> Message-ID: On Tue, Aug 21, 2012 at 8:32 AM, Simon Marlow wrote: > I'm not sure how to interpret that result - at the least, it suggests a > certain lack of enthusiasm. > I would like to see the async package go in. I have hand-rolled something like it a couple of times. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bos at serpentine.com Tue Aug 21 17:55:40 2012 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue, 21 Aug 2012 08:55:40 -0700 Subject: HP 2012.4.0.0 -- Call for Proposals In-Reply-To: References: Message-ID: On Tue, Aug 21, 2012 at 6:43 AM, Mark Lentczner wrote: > *Outstanding work:* > I believe there was also a proposal to include the split package: http://trac.haskell.org/haskell-platform/wiki/Proposals/split -------------- next part -------------- An HTML attachment was scrubbed... URL: From felipe.lessa at gmail.com Tue Aug 21 17:56:18 2012 From: felipe.lessa at gmail.com (Felipe Almeida Lessa) Date: Tue, 21 Aug 2012 12:56:18 -0300 Subject: HP 2012.4.0.0 -- Call for Proposals In-Reply-To: References: <5033AA21.8070703@gmail.com> Message-ID: Is it time for votes yet? +1 for async =). -- Felipe. From johan.tibell at gmail.com Tue Aug 21 18:26:46 2012 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 21 Aug 2012 09:26:46 -0700 Subject: HP 2012.4.0.0 -- Call for Proposals In-Reply-To: References: <5033AA21.8070703@gmail.com> Message-ID: On Tue, Aug 21, 2012 at 8:54 AM, Bryan O'Sullivan wrote: > On Tue, Aug 21, 2012 at 8:32 AM, Simon Marlow wrote: >> >> I'm not sure how to interpret that result - at the least, it suggests a >> certain lack of enthusiasm. > > > I would like to see the async package go in. I have hand-rolled something > like it a couple of times. Having just read through the API, which is very well-written, I'd like to see this go in as well. -- Johan From byorgey at seas.upenn.edu Tue Aug 21 19:12:36 2012 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Tue, 21 Aug 2012 13:12:36 -0400 Subject: HP 2012.4.0.0 -- Call for Proposals In-Reply-To: References:

Message-ID: <20120821171236.GA16448@seas.upenn.edu> On Tue, Aug 21, 2012 at 08:55:40AM -0700, Bryan O'Sullivan wrote: > On Tue, Aug 21, 2012 at 6:43 AM, Mark Lentczner wrote: > > > *Outstanding work:* > > > > I believe there was also a proposal to include the split package: > http://trac.haskell.org/haskell-platform/wiki/Proposals/split Indeed. I plan to release a new version (incorporating feedback) and bump the process soon. -Brent From allbery.b at gmail.com Tue Aug 21 19:24:44 2012 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 21 Aug 2012 13:24:44 -0400 Subject: HP 2012.4.0.0 -- Call for Proposals In-Reply-To: <5033AA21.8070703@gmail.com> References: <5033AA21.8070703@gmail.com> Message-ID: On Tue, Aug 21, 2012 at 11:32 AM, Simon Marlow wrote: > I'm still keen to see the package go in, mainly because when you start > doing concurrent programming you quite quickly run into the need for I think most of us are of the opinion that it would be nice to see it get some independent use and shake the bugs and infelicities out of it first; being in the platform implies (correctly or not) a certain level of interface stability and trust in functionality. -- brandon s allbery allbery.b at gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Tue Aug 21 20:05:50 2012 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 21 Aug 2012 11:05:50 -0700 Subject: HP 2012.4.0.0 -- Call for Proposals In-Reply-To: References: <5033AA21.8070703@gmail.com> Message-ID: On Tue, Aug 21, 2012 at 10:24 AM, Brandon Allbery wrote: > On Tue, Aug 21, 2012 at 11:32 AM, Simon Marlow wrote: >> >> I'm still keen to see the package go in, mainly because when you start >> doing concurrent programming you quite quickly run into the need for > > > I think most of us are of the opinion that it would be nice to see it get > some independent use and shake the bugs and infelicities out of it first; > being in the platform implies (correctly or not) a certain level of > interface stability and trust in functionality. Is the time until the actual release enough? If not we can accept the package now but not include it until the next release, at which point any obvious bugs should be gone. Simon, has the package seen any use (e.g. in one of your classes) yet? From danburton.email at gmail.com Tue Aug 21 20:34:52 2012 From: danburton.email at gmail.com (Dan Burton) Date: Tue, 21 Aug 2012 12:34:52 -0600 Subject: HP 2012.4.0.0 -- Call for Proposals In-Reply-To: References: <5033AA21.8070703@gmail.com>

Message-ID: Both split and async fit well with the "batteries included" nature of the platform. Regardless of how much use it has seen, async is definitely an API that should be bundled with the "standard" libraries. Compare with, say, Java or Python standard libs; programmers expect modern languages to expose easy-to-use concurrency operations. Most of the async definitions are thin convenience wrappers around Control.Concurrent, so as long as we are comfortable with Control.Concurrent, I see no reason to worry about async. In my unprofessional opinion, it's high time we add async to the platform. -- Dan Burton -------------- next part -------------- An HTML attachment was scrubbed... URL: From byorgey at seas.upenn.edu Tue Aug 21 20:48:28 2012 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Tue, 21 Aug 2012 14:48:28 -0400 Subject: Call for consensus: addition of split package to platform Message-ID: <20120821184828.GA25437@seas.upenn.edu> Hi everyone, Following the great feedback I got on the initial proposal, and after testing with the GHC 7.6 release candidate, I have just released split-0.2.0.0, which I am proposing for inclusion in the HP. The full proposal, links to previous discussion, etc. can be found on the wiki: http://trac.haskell.org/haskell-platform/wiki/Proposals/split Comments, questions, constructive criticism, etc. are still welcome, but this time around I hope we can build a consensus as to whether it should go in the platform or not. I would also like people's opinions on the one big question remaining: whether to use cabal's mechanisms to conditionally include some code, allowing the 'build' function to be taken from GHC.Exts when available, or defined manually otherwise. This would make split fully H2010-compatible. The currently released version does NOT include this, so it is H2010-compatible but GHC specific. The options are: 1) just use a generic version of 'build' (simplest option) 2) use only GHC's version of build (slightly faster) 3) do the conditional thing to choose between 1) and 2) at compile time (most general but most complicated/cumbersome) -Brent From lemming at henning-thielemann.de Tue Aug 21 20:55:40 2012 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 21 Aug 2012 20:55:40 +0200 (CEST) Subject: Call for consensus: addition of split package to platform In-Reply-To: <20120821184828.GA25437@seas.upenn.edu> References: <20120821184828.GA25437@seas.upenn.edu> Message-ID: On Tue, 21 Aug 2012, Brent Yorgey wrote: > I would also like people's opinions on the one big question remaining: > whether to use cabal's mechanisms to conditionally include some code, > allowing the 'build' function to be taken from GHC.Exts when > available, or defined manually otherwise. This would make split fully > H2010-compatible. The currently released version does NOT include > this, so it is H2010-compatible but GHC specific. The options are: > > 1) just use a generic version of 'build' (simplest option) > > 2) use only GHC's version of build (slightly faster) > > 3) do the conditional thing to choose between 1) and 2) at compile > time (most general but most complicated/cumbersome) The best solution would be to have a package that provides the 'build' function for all compilers. For GHC it exports the fusing 'build' and for other compilers it exports a generic version. I think this 'build' function is useful for other packages, too. This package does not yet exist and if it would exist then it should or must be part of the platform. For now I would think a simple solution is ok, thus I vote for solution number 1. Later you can simply switch the import of 'build'. From gale at sefer.org Wed Aug 22 07:29:59 2012 From: gale at sefer.org (Yitzchak Gale) Date: Wed, 22 Aug 2012 08:29:59 +0300 Subject: HP 2012.4.0.0 -- Call for Proposals In-Reply-To: References: Message-ID: On Tue, Aug 21, 2012, Mark Lentczner wrote: > Please see the process for > [Adding Packages](http://trac.haskell.org/haskell-platform/wiki/AddingPackages). > > Outstanding work... Just to clarify: Since Mark referenced the policy page, I assume that means we need to adhere to it at least to some degree before a package can be added to the platform. If so, there must be a proposal page on the Trac Wiki before we can consider a package. Therefore, there is only ONE package so far that is a candidate: async. A proposal page can be created by anyone, not just the package maintainer. So if you are in favor of a package other than async, you might better spend your time working on a wiki page instead of "voting" for a non-proposal. All that said, it seems to me that we might not need quite so much formal process for each package addition. If there is serious discussion on these lists, I personally would be willing to entrust the final decision to a benevolent dictator. We could save the formal process for periodic selection of the dictator. A number of open source projects work in this way. Thanks, Yitz From johan.tibell at gmail.com Wed Aug 22 07:50:54 2012 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 21 Aug 2012 22:50:54 -0700 Subject: HP 2012.4.0.0 -- Call for Proposals In-Reply-To: References:

Message-ID: On Tuesday, August 21, 2012, Yitzchak Gale wrote: > On Tue, Aug 21, 2012, Mark Lentczner wrote: > > Please see the process for > > [Adding Packages]( > http://trac.haskell.org/haskell-platform/wiki/AddingPackages). > > > > Outstanding work... > > Just to clarify: > > Since Mark referenced the policy page, I assume that > means we need to adhere to it at least to some degree > before a package can be added to the platform. > > If so, there must be a proposal page on the Trac Wiki > before we can consider a package. Therefore, there > is only ONE package so far that is a candidate: async. There is also one for vector: http://trac.haskell.org/haskell-platform/wiki/Proposals/vector -------------- next part -------------- An HTML attachment was scrubbed... URL: From gale at sefer.org Wed Aug 22 10:27:13 2012 From: gale at sefer.org (Yitzchak Gale) Date: Wed, 22 Aug 2012 11:27:13 +0300 Subject: HP 2012.4.0.0 -- Call for Proposals In-Reply-To: References:

Message-ID: Johan Tibell wrote: > There is also one for vector: > http://trac.haskell.org/haskell-platform/wiki/Proposals/vector Ah, sorry. I didn't notice it at first because it wasn't on the list of active proposals: http://trac.haskell.org/haskell-platform/wiki/Proposals I added it. Now I see that Brent has created a proposal page for the split package; I added that as well. There is one more active proposal that Mark did not mention: the time-extras package, proposed by its author, Ashley Yakeley. I added a link to that, too. Thanks, Yitz From gale at sefer.org Wed Aug 22 10:40:57 2012 From: gale at sefer.org (Yitzchak Gale) Date: Wed, 22 Aug 2012 11:40:57 +0300 Subject: Add binary and/or cereal to the Haskell Platform Message-ID: I see that several years ago a proposal page was prepared for adding the binary package to the Haskell Platform, but it was never actually submitted as a proposal. http://trac.haskell.org/haskell-platform/wiki/Proposals/binary I think the reason it was not submitted was that things were in flux at that time regarding the binary and cereal packages. Now the situation has settled down. I think one or both of those packages ought to be added to the platform. Any opinions? Thanks, Yitz From marlowsd at gmail.com Wed Aug 22 13:09:50 2012 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 22 Aug 2012 12:09:50 +0100 Subject: HP 2012.4.0.0 -- Call for Proposals In-Reply-To: References: <5033AA21.8070703@gmail.com>

Message-ID: <5034BDFE.80004@gmail.com> On 21/08/2012 19:05, Johan Tibell wrote: > On Tue, Aug 21, 2012 at 10:24 AM, Brandon Allbery wrote: >> On Tue, Aug 21, 2012 at 11:32 AM, Simon Marlow wrote: >>> >>> I'm still keen to see the package go in, mainly because when you start >>> doing concurrent programming you quite quickly run into the need for >> >> >> I think most of us are of the opinion that it would be nice to see it get >> some independent use and shake the bugs and infelicities out of it first; >> being in the platform implies (correctly or not) a certain level of >> interface stability and trust in functionality. > > Is the time until the actual release enough? If not we can accept the > package now but not include it until the next release, at which point > any obvious bugs should be gone. > > Simon, has the package seen any use (e.g. in one of your classes) yet? The API is actually developed in my tutorial (which will become the book) from first principles, starting from MVars and then moving to STM, as a way to motivate and explain the underlying primitives. Basic versions of the API are used in several of the examples, although I'm not using the async package itself yet - the examples came first. I don't see any reverse deps on async in Hackage yet. Perhaps I need to write a blog post about it... Cheers, Simon From mark.lentczner at gmail.com Wed Aug 22 16:32:54 2012 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Wed, 22 Aug 2012 07:32:54 -0700 Subject: HP 2012.4.0.0 -- Call for Proposals In-Reply-To: <5034BDFE.80004@gmail.com> References: <5033AA21.8070703@gmail.com>

<5034BDFE.80004@gmail.com> Message-ID: Thank you, Yitz, for the wiki maintenance! *vector* and *time-extras *- these should be updated by the proposers as they have been "reproposed" *async*, *vector*, and *time-extras* - I think these all need to be updated to reflect the current discussion period. While required by the process, I'd urge proposers to link to the specific version of the package under consideration. While the proposal is for inclusion of the package going forward (hence evolving versions over time), it really helps API discussions to pin them to a particular version. If discussion causes you to update a package, then the proposal discussion can "re-vector" to the new version. Please split discussion of particular proposals off from this thread. Lastly, just to be clear, the dates I set out are the dates by which I need proposals handled and decided in order to get the release out on schedule. The proposal process is not tied to releases, and can continue aysnc from release if any proposal needs time-extra. - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Wed Aug 22 17:05:01 2012 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed, 22 Aug 2012 08:05:01 -0700 Subject: Add binary and/or cereal to the Haskell Platform In-Reply-To: References: Message-ID: Hi all, On Wed, Aug 22, 2012 at 1:40 AM, Yitzchak Gale wrote: > I see that several years ago a proposal page was prepared > for adding the binary package to the Haskell Platform, > but it was never actually submitted as a proposal. > > http://trac.haskell.org/haskell-platform/wiki/Proposals/binary > > I think the reason it was not submitted was that things > were in flux at that time regarding the binary and cereal > packages. > > Now the situation has settled down. I think one or both > of those packages ought to be added to the platform. > Any opinions? As I've mentioned before [1] I think binary and cereal should be merged. They are almost identical and both the strict (cereal) and lazy (binary) runGet interfaces can coexist in the same API, implemented on top of runGetPartial. The only remaining issue I'm aware of is that Lennart tried implementing the current binary API using continuations and it was a bit tricky to maintain performance. Furthermore, I really think the Put and Get modules should be split, which implement encoding/decoding of base types in standardized encodings, should be split from the Binary/Cereal module, which implement a very specific and non-standardized (but still useful) format. Not not break any old code I suggest that the binary/cereal package will re-export this split off API (e.g. a new binary-encodings package). 1. http://blog.johantibell.com/2011/01/merging-binary-and-cereal.html -- Johan From gale at sefer.org Wed Aug 22 17:20:02 2012 From: gale at sefer.org (Yitzchak Gale) Date: Wed, 22 Aug 2012 18:20:02 +0300 Subject: Add binary and/or cereal to the Haskell Platform In-Reply-To: References:

Message-ID: Hi Johan, Johan Tibell wrote: > As I've mentioned before [1] I think binary and cereal should be > merged.... [other proposed API improvements] > 1. http://blog.johantibell.com/2011/01/merging-binary-and-cereal.html Yes, those are great ideas. The thing is, nobody (myself included of course) has done anything about it for almost two years. Right now, binary and cereal are what they are. These are important packages that are popular dependencies. I observe empirically that their APIs are extremely stable. Unless there is new evidence that someone will work on them in the very near future and change the APIs significantly, I think they should go into the platform the way they are now. Or at least one of the two. I'd like to hear other opinions on that, though. Better yet - here's an easy chance for someone to step up, be a hero, and become famous. Thanks, Yitz From johan.tibell at gmail.com Wed Aug 22 18:29:57 2012 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed, 22 Aug 2012 09:29:57 -0700 Subject: Add binary and/or cereal to the Haskell Platform In-Reply-To: References:

Message-ID: On Wed, Aug 22, 2012 at 8:20 AM, Yitzchak Gale wrote: > Hi Johan, > > Johan Tibell wrote: >> As I've mentioned before [1] I think binary and cereal should be >> merged.... [other proposed API improvements] >> 1. http://blog.johantibell.com/2011/01/merging-binary-and-cereal.html > > Yes, those are great ideas. The thing is, nobody > (myself included of course) has done anything about > it for almost two years. Right now, binary and cereal > are what they are. These are important packages that > are popular dependencies. I observe empirically > that their APIs are extremely stable. Unless there is > new evidence that someone will work on them in the > very near future and change the APIs significantly, > I think they should go into the platform the way they > are now. Or at least one of the two. I agree with this sentiment. My current thinking is that perhaps it's better to leave both out. I don't feel too strongly about it though. If binary went in we might convince Lennart to finish and release his "cps" branch which should give binary incremental input capabilities. -- Johan From dons00 at gmail.com Wed Aug 22 19:26:55 2012 From: dons00 at gmail.com (Don Stewart) Date: Wed, 22 Aug 2012 11:26:55 -0600 Subject: Add binary and/or cereal to the Haskell Platform In-Reply-To: References:

Message-ID: I'd say put the strict bs (cereal) and lazy bs (binary) in. On Wednesday, August 22, 2012, Johan Tibell wrote: > On Wed, Aug 22, 2012 at 8:20 AM, Yitzchak Gale > > wrote: > > Hi Johan, > > > > Johan Tibell wrote: > >> As I've mentioned before [1] I think binary and cereal should be > >> merged.... [other proposed API improvements] > >> 1. http://blog.johantibell.com/2011/01/merging-binary-and-cereal.html > > > > Yes, those are great ideas. The thing is, nobody > > (myself included of course) has done anything about > > it for almost two years. Right now, binary and cereal > > are what they are. These are important packages that > > are popular dependencies. I observe empirically > > that their APIs are extremely stable. Unless there is > > new evidence that someone will work on them in the > > very near future and change the APIs significantly, > > I think they should go into the platform the way they > > are now. Or at least one of the two. > > I agree with this sentiment. My current thinking is that perhaps it's > better to leave both out. I don't feel too strongly about it though. > If binary went in we might convince Lennart to finish and release his > "cps" branch which should give binary incremental input capabilities. > > -- Johan > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: