From nvd1234 at gmail.com Fri Nov 1 11:42:06 2013 From: nvd1234 at gmail.com (Nathan van Doorn) Date: Fri, 1 Nov 2013 11:42:06 +0000 Subject: Add laws to Alternative Message-ID: Proposal: add the following laws to the documentation of Control.Applicative.Alternative: - empty <*> a = empty - f <*> empty = empty These laws correspond to the laws given in MonadPlus- if you take mzero = empty and ap = (<*>), the ones in MonadPlus imply these- and I don't think this proposal should be too controversial. Time limit: 1 week Nathan "Taneb" van Doorn -------------- next part -------------- An HTML attachment was scrubbed... URL: From twanvl at gmail.com Fri Nov 1 12:09:15 2013 From: twanvl at gmail.com (Twan van Laarhoven) Date: Fri, 01 Nov 2013 12:09:15 +0000 Subject: Add laws to Alternative In-Reply-To: References: Message-ID: <527399EB.4020901@gmail.com> On 01/11/13 11:42, Nathan van Doorn wrote: > Proposal: add the following laws to the documentation of > Control.Applicative.Alternative: > > * empty <*> a = empty > * f <*> empty = empty > > These laws correspond to the laws given in MonadPlus- if you take mzero = > empty and ap = (<*>), the ones in MonadPlus imply these- and I don't think > this proposal should be too controversial. As far as I can see, the documentation for MonadPlus does not specify these laws anywhere [1,2]. Consider the IO monad. These laws claim that launchMissiles *> fail "empty" = fail "empty" This is clearly *not* true. -- If we add laws, I think we should first consider the much more reasonable monoid laws identity empty <|> a = a a <|> empty = a associativity: (a <|> b) <|> c = a <|> (b <|> c) In the MonadPlus world, the controversial part is the choice between left distribution (f <|> g) <*> a = (f <*> a) <|> (g <*> a) or left catch pure a <|> b = pure a Your proposal would be left zero empty <*> a = empty right zero f <*> empty = empty And as mentioned above, right zero is problematic. The fmap version should be okay though map zero f <$> empty = empty Twan [1] http://hackage.haskell.org/package/base-4.6.0.1/docs/Control-Monad.html#t:MonadPlus [2] http://www.haskell.org/haskellwiki/MonadPlus From twanvl at gmail.com Fri Nov 1 13:08:31 2013 From: twanvl at gmail.com (Twan van Laarhoven) Date: Fri, 01 Nov 2013 13:08:31 +0000 Subject: Add laws to Alternative In-Reply-To: References: <527399EB.4020901@gmail.com> Message-ID: <5273A7CF.3030709@gmail.com> On 01/11/13 12:44, Nathan van Doorn wrote: > Firstly, I don't see how IO is relevant here, it has neither a MonadPlus > instance nor an Alternative instance. You are right. I thought it was an instance with mzero=fail "foo" and mplus=catch. But I was apparently mistaken. Objection withdrawn. > Secondly, the MonadPlus laws are documented in Control.Monad to be: > > mzero >>= f = mzero > v >> mzero = mzero I missed them, because they are written in the documentation of mzero rather than the documentation of the class where I expected them. > Thirdly, the monoid laws are already documented. (<|>) must be "An associative > binary operation", and empty "The identity of <|>". These are exactly the monoid > laws. Perhaps they should be made more explicit, but that is a different issue. Missed this as well. > Fourthly, [] fulfils neither the left-distribution law or the left-catch law, > and I doubt many people would be happy to lose []'s MonadPlus instance. List does satisfy left distribution: ?> (,) <$> ([1,2] <|> [3]) <*> [4,5] [(1,4),(1,5),(2,4),(2,5),(3,4),(3,5)] ?> (,) <$> [1,2] <*> [4,5] <|> (,) <$> [3] <*> [4,5] [(1,4),(1,5),(2,4),(2,5),(3,4),(3,5)] ?> quickCheck (\x y z -> ((,) <$> (x <|> y :: [Int]) <*> (z :: [Int])) == (((,) <$> x <*> z) <|> ((,) <$> y <*> z))) +++ OK, passed 100 tests. See also http://www.haskell.org/haskellwiki/MonadPlus. Then law which it doesn't is right distribution. Consider Maybe. it does satisfies left catch but not left distribution for MonadPlus. Since mplus (Just False >>= guard) (Just True >>= guard) = Just () while mplus (Just False) (Just True) >>= guard = Nothing But for Alternative, you can't have the failure of the second argument of (<*>) depend on the first. So Maybe *does* satisfy left distribution for Alternative. IMO that makes it a good candidate law. Twan > I believe I have addressed all your issues. If I've missed something, please > point it out to me. > > Nathan. > > > On 1 November 2013 12:09, Twan van Laarhoven > wrote: > > On 01/11/13 11:42, Nathan van Doorn wrote: > > Proposal: add the following laws to the documentation of > Control.Applicative.__Alternative: > > * empty <*> a = empty > * f <*> empty = empty > > > These laws correspond to the laws given in MonadPlus- if you take mzero = > > empty and ap = (<*>), the ones in MonadPlus imply these- and I don't think > > this proposal should be too controversial. > > As far as I can see, the documentation for MonadPlus does not specify these > laws anywhere [1,2]. > > Consider the IO monad. These laws claim that > > launchMissiles *> fail "empty" = fail "empty" > > This is clearly *not* true. > > -- > > If we add laws, I think we should first consider the much more reasonable > monoid laws > > identity > empty <|> a = a > a <|> empty = a > associativity: > (a <|> b) <|> c = a <|> (b <|> c) > > In the MonadPlus world, the controversial part is the choice between > > left distribution > (f <|> g) <*> a = (f <*> a) <|> (g <*> a) > > or > > left catch > pure a <|> b = pure a > > Your proposal would be > > left zero > > empty <*> a = empty > right zero > > f <*> empty = empty > > And as mentioned above, right zero is problematic. The fmap version should > be okay though > > map zero > f <$> empty = empty > > > Twan > > [1] > http://hackage.haskell.org/__package/base-4.6.0.1/docs/__Control-Monad.html#t:MonadPlus > > [2] http://www.haskell.org/__haskellwiki/MonadPlus > > _________________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/__mailman/listinfo/libraries > > > From roconnor at theorem.ca Sun Nov 3 16:20:41 2013 From: roconnor at theorem.ca (roconnor at theorem.ca) Date: Sun, 3 Nov 2013 11:20:41 -0500 (EST) Subject: traverseWithKey for Data.Map et. al. Message-ID: Has there yet been a proposal for adding traverseWithKey :: Applicative f => (k -> a -> f b) -> Map k a -> f (Map k b) to Data.Map and friends yet? If not I'll draw up a proposal. -- 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 Sun Nov 3 18:13:52 2013 From: roconnor at theorem.ca (roconnor at theorem.ca) Date: Sun, 3 Nov 2013 13:13:52 -0500 (EST) Subject: traverseWithKey for Data.Map et. al. In-Reply-To: References: Message-ID: On Sun, 3 Nov 2013, roconnor at theorem.ca wrote: > Has there yet been a proposal for adding > > traverseWithKey :: Applicative f => (k -> a -> f b) -> Map k a -> f (Map k b) > > to Data.Map and friends yet? > > If not I'll draw up a proposal. Oops, it has been drawn to my attention that this function already exists. I was looking at very outdated docs. Sorry. -- 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 bgamari.foss at gmail.com Fri Nov 8 17:02:01 2013 From: bgamari.foss at gmail.com (Ben Gamari) Date: Fri, 08 Nov 2013 12:02:01 -0500 Subject: mersenne-random-pure64 and GHC 7.7 In-Reply-To: References: <87ob7i9se6.fsf@gmail.com> <87ob5y2y4p.fsf@gmail.com> Message-ID: <874n7m25fa.fsf@gmail.com> Don Stewart writes: > Please go ahead. > > Thanks! > Could someone give me the required Hackage privileges for mersenne-random-pure64 for I can make this happen? Thanks! - Ben > On Wednesday, 6 November 2013, Ben Gamari wrote: > >> Ben Gamari > writes: >> >> > Attached are two patches. One updates your contact information and the >> > other makes mersenne-random-pure64 buildable on GHC 7.7. It would be >> > great if you could push a release to Hackage with these patches. >> > >> Could you push these to Hackage? >> >> In case you are interested, I've converted the repository to git and >> pushed it up to github[1]. I would be happy to push a new release to >> Hackage for you if this would be easier. >> >> Cheers, >> >> - Ben >> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From mark.lentczner at gmail.com Sun Nov 10 16:11:42 2013 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sun, 10 Nov 2013 08:11:42 -0800 Subject: 2013.4.0.0 proposal Message-ID: I know it is late, and so I've done some preliminary version sleuthing.... Here's my proposal for HP 2013.4.0.0. I know this e-mail's is long - but hoping to hear from all relevant parties soon. *GHC 7.6.3* -- this is a compiler bump, but all the included packages remain at the same version as 2013.2.0.0 *Packages with no changes:* fgl, haskell-src, html, HTTP, HUnit, mtl, parsec, QuickCheck, random, regex-base, regex-compat, regex-posix, split, stm, text, transformers, xhtml, zlib *Packages with minor version bumps:* *I'll advance these automatically this time - no need for maintainer input* cgi: 3001.1.7.5 ? 3001.1.8.4 network: 2.4.1.2 ? 2.4.2.0 parallel: 3.2.0.3 ? 3.2.0.4 syb: 0.4.0 ? 0.4.1 unordered-containers: 0.2.3.0 ? 0.2.3.3 vector: 0.10.0.1 ? 0.10.9.1? primitive: 0.5.0.1 ? 0.5.1.0? *Packages with major version bumps:* *I'd like to get confirmation from the maintainers of these packages that this bump is "the right thing to do". The bump should ideally only add API, and not orphan any program that used to compile under the HP - at least not without a good reason.* case-insensitive: 1.0.0.1 ? 1.1.0.1 hashable: 1.1.2.5 ? 1.2.1.0 GLUT: 2.4.0.0 ? 2.5.0.1 GLURaw: 1.3.0.0 ? 1.4.0.0 OpenGL: 2.8.0.0 ? 2.9.1.0 OpenGLRaw: 1.3.0.0 ? 1.4.0.0 alex: 3.0.5 ? 3.1.0 happy: 1.18.10 ? 1.19.0 *New Packages:* *There was prior discussion on the libraries mailing list, and generally all around resounding "YES!" for including aeson.* *I think we should include it. I'm looking for confirmation from the maintainer that this is the right version to include.* aeson: 0.6.2.1 *Cabal:* *The Cabal 1.18 release was a major new release, including the very very useful sandbox feature. This would require shipping a different Cabal lib than the version shipped with the included GHC. I'm not sure of the implications of doing this - in particular, whether we would have to ship two Cabal packages or just the later.* Cabal: 1.16.0 ? 1.18.1.2 cabal-install: 1.16.0.2 ? 1.18.0.2 What do you all think? ? Mark "late, but not forgotten" Lentczner -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Sun Nov 10 16:46:18 2013 From: johan.tibell at gmail.com (Johan Tibell) Date: Sun, 10 Nov 2013 17:46:18 +0100 Subject: 2013.4.0.0 proposal In-Reply-To: References: Message-ID: hashable bump is good. I'm also pro shipping a newer Cabal, if it doesn't cause any issues with the one that already comes with GHC. On Sun, Nov 10, 2013 at 5:11 PM, Mark Lentczner wrote: > I know it is late, and so I've done some preliminary version sleuthing.... > Here's my proposal for HP 2013.4.0.0. I know this e-mail's is long - but > hoping to hear from all relevant parties soon. > > *GHC 7.6.3* -- this is a compiler bump, but all the included packages > remain at the same version as 2013.2.0.0 > > *Packages with no changes:* > fgl, haskell-src, html, HTTP, HUnit, > mtl, parsec, QuickCheck, random, > regex-base, regex-compat, regex-posix, > split, stm, text, transformers, > xhtml, zlib > > *Packages with minor version bumps:* > *I'll advance these automatically this time - no need for maintainer input* > cgi: 3001.1.7.5 ? 3001.1.8.4 > network: 2.4.1.2 ? 2.4.2.0 > parallel: 3.2.0.3 ? 3.2.0.4 > syb: 0.4.0 ? 0.4.1 > unordered-containers: 0.2.3.0 ? 0.2.3.3 > vector: 0.10.0.1 ? 0.10.9.1? > primitive: 0.5.0.1 ? 0.5.1.0? > > *Packages with major version bumps:* > *I'd like to get confirmation from the maintainers of these packages that > this bump is "the right thing to do". The bump should ideally only add API, > and not orphan any program that used to compile under the HP - at least not > without a good reason.* > case-insensitive: 1.0.0.1 ? 1.1.0.1 > hashable: 1.1.2.5 ? 1.2.1.0 > > GLUT: 2.4.0.0 ? 2.5.0.1 > GLURaw: 1.3.0.0 ? 1.4.0.0 > OpenGL: 2.8.0.0 ? 2.9.1.0 > OpenGLRaw: 1.3.0.0 ? 1.4.0.0 > > alex: 3.0.5 ? 3.1.0 > happy: 1.18.10 ? 1.19.0 > > *New Packages:* > *There was prior discussion on the libraries mailing list, and generally > all around resounding "YES!" for including aeson.* > *I think we should include it. I'm looking for confirmation from the > maintainer that this is the right version to include.* > aeson: 0.6.2.1 > > *Cabal:* > *The Cabal 1.18 release was a major new release, including the very very > useful sandbox feature. This would require shipping a different Cabal lib > than the version shipped with the included GHC. I'm not sure of the > implications of doing this - in particular, whether we would have to ship > two Cabal packages or just the later.* > Cabal: 1.16.0 ? 1.18.1.2 > cabal-install: 1.16.0.2 ? 1.18.0.2 > > What do you all think? > > ? Mark "late, but not forgotten" Lentczner > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Sun Nov 10 17:15:11 2013 From: svenpanne at gmail.com (Sven Panne) Date: Sun, 10 Nov 2013 18:15:11 +0100 Subject: 2013.4.0.0 proposal In-Reply-To: References: Message-ID: 2013/11/10 Mark Lentczner : > [...] Packages with major version bumps: > I'd like to get confirmation from the maintainers of these packages that > this bump is "the right thing to do". The bump should ideally only add API, > and not orphan any program that used to compile under the HP - at least not > without a good reason. > [...] > GLUT: 2.4.0.0 ? 2.5.0.1 > GLURaw: 1.3.0.0 ? 1.4.0.0 > OpenGL: 2.8.0.0 ? 2.9.1.0 > OpenGLRaw: 1.3.0.0 ? 1.4.0.0 > [...] All those bumps are OK. There are a few API incompatibilities, but these were actually driven by user demand, see the HOpenGL mailing list archive/GitHub issue trackers. Fixing any program/library which doesn't compile with the new versions is only a tiny mechanical task. I'm quite aware of the fact that breaking APIs is not nice, but OpenGL itself has changed so much over the last few years that the old API was simply wrong in some places. From mark.lentczner at gmail.com Sun Nov 10 21:40:14 2013 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sun, 10 Nov 2013 13:40:14 -0800 Subject: 2013.4.0.0 proposal In-Reply-To: References: Message-ID: Including aeson, which I think we'd all very much like to do, requires dlist-0.5. Now, dlist has been around for a very long time, and is very stable. I do not believe that dlist's API is exposed indirectly via aeson at all. I hereby propose that it be added to the platform. At the very least, it could be like primitive - in the platform, but not "part" of it. Thoughts? - Mark ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Sun Nov 10 21:41:55 2013 From: johan.tibell at gmail.com (Johan Tibell) Date: Sun, 10 Nov 2013 22:41:55 +0100 Subject: 2013.4.0.0 proposal In-Reply-To: References: Message-ID: Fine by me. On Sun, Nov 10, 2013 at 10:40 PM, Mark Lentczner wrote: > Including aeson, which I think we'd all very much like to do, requires > dlist-0.5. > Now, dlist has been around for a very long time, and is very stable. > I do not believe that dlist's API is exposed indirectly via aeson at all. > > I hereby propose that it be added to the platform. > At the very least, it could be like primitive - in the platform, but not > "part" of it. > > Thoughts? > > - Mark > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Sun Nov 10 22:14:18 2013 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sun, 10 Nov 2013 14:14:18 -0800 Subject: 2013.4.0.0 proposal In-Reply-To: References: Message-ID: I spoke too soon: *aeson* induces *blaze-builder* & *dlist* -- both are pretty long term established and stable - I say include 'em both. *cgi* 3001.1.8.4 induces *MonadCatchIO-mtl* & *extensible-exceptions* - this is more problematic: - *extensible-exceptions* hasn't been needed since GHC 7, and just reexports stuff into a different place. I don't think that should be in the platform. - *MonadCatchIO-mtl* is one of several approaches to re-mapping extensible exceptions into *mtl*. While none is settled practice yet, this one is probably a dead end as it uses the older block/unblock idiom rather than the now preferred mask idiom. I'm planning holding *cgi* back to 3001.1.7.5 to avoid these two packages. thoughts always welcome! - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Sun Nov 10 22:33:31 2013 From: ekmett at gmail.com (Edward Kmett) Date: Sun, 10 Nov 2013 23:33:31 +0100 Subject: Proposal: Add `instance Bits Bool` Message-ID: We went through all the pain of removing Num as a superclass of Bits to support it, but we apparently never actually put the instance of Bits (and FiniteBits) for Bool into base. I propose we do so. Discussion Period: 2 weeks -Edward -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Sun Nov 10 22:46:50 2013 From: johan.tibell at gmail.com (Johan Tibell) Date: Sun, 10 Nov 2013 23:46:50 +0100 Subject: 2013.4.0.0 proposal In-Reply-To: References: Message-ID: blaze-builder is a bit troublesome as we've merged that package into bytestring now and we want users to use that interface. On Sun, Nov 10, 2013 at 11:14 PM, Mark Lentczner wrote: > I spoke too soon: > > *aeson* induces *blaze-builder* & *dlist* -- both are pretty long term > established and stable - I say include 'em both. > > *cgi* 3001.1.8.4 induces *MonadCatchIO-mtl* & *extensible-exceptions* - > this is more problematic: > > - *extensible-exceptions* hasn't been needed since GHC 7, and just > reexports stuff into a different place. I don't think that should be in the > platform. > - *MonadCatchIO-mtl* is one of several approaches to re-mapping > extensible exceptions into *mtl*. While none is settled practice yet, > this one is probably a dead end as it uses the older block/unblock idiom > rather than the now preferred mask idiom. > > I'm planning holding *cgi* back to 3001.1.7.5 to avoid these two packages. > > thoughts always welcome! > > - Mark > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Sun Nov 10 22:49:01 2013 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sun, 10 Nov 2013 14:49:01 -0800 Subject: 2013.4.0.0 proposal In-Reply-To: References: Message-ID: Is the API actually different, or just at a different module location? In either case, are you planning on exporting a backward compatible interface for some time from bytestring? Realize that bytestring comes with GHC, so how long before we're likely to see this blaze-builder in a release? - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Sun Nov 10 23:00:17 2013 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 11 Nov 2013 00:00:17 +0100 Subject: 2013.4.0.0 proposal In-Reply-To: References: Message-ID: * The API is actually (a bit) different. * We weren't planning to offer a compatibility API through bytestring, but the blaze-builder implementation might be in terms of bytestring. * The bytestring builder has been out since bytestring-0.10 On Sun, Nov 10, 2013 at 11:49 PM, Mark Lentczner wrote: > Is the API actually different, or just at a different module location? > In either case, are you planning on exporting a backward compatible > interface for some time from bytestring? > > Realize that bytestring comes with GHC, so how long before we're likely to > see this blaze-builder in a release? > > - Mark > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shelarcy at gmail.com Mon Nov 11 02:50:07 2013 From: shelarcy at gmail.com (shelarcy) Date: Mon, 11 Nov 2013 11:50:07 +0900 Subject: Request to release cabal-install 1.18.0.3 (Was: 2013.4.0.0 proposal In-Reply-To: References: Message-ID: Hi, cabal-install 1.18.0.2 has two critical bugs on Windows. 1. "cabal sdist" command make broken tarball on Windows. https://github.com/haskell/cabal/issues/1538 2. "cabal update" command broke package index sometimes. https://twitter.com/xyx_is/status/391944129074044929 (in Japanese) Both bugs are already fixed in 1.18 branch's cabal-install (with Cabal 1.18.1.2). But that version isn't released yet. So, please release newer version of cabal-install before releasing HP 2013.4.0.0. Best Regards, On Mon, 11 Nov 2013 01:46:18 +0900, Johan Tibell wrote: > hashable bump is good. I'm also pro shipping a newer Cabal, if it doesn't > cause any issues with the one that already comes with GHC. > > > On Sun, Nov 10, 2013 at 5:11 PM, Mark Lentczner wrote: > >> I know it is late, and so I've done some preliminary version sleuthing.... >> Here's my proposal for HP 2013.4.0.0. I know this e-mail's is long - but >> hoping to hear from all relevant parties soon. >> >> *GHC 7.6.3* -- this is a compiler bump, but all the included packages >> remain at the same version as 2013.2.0.0 >> >> *Packages with no changes:* >> fgl, haskell-src, html, HTTP, HUnit, >> mtl, parsec, QuickCheck, random, >> regex-base, regex-compat, regex-posix, >> split, stm, text, transformers, >> xhtml, zlib >> >> *Packages with minor version bumps:* >> *I'll advance these automatically this time - no need for maintainer input* >> cgi: 3001.1.7.5 ? 3001.1.8.4 >> network: 2.4.1.2 ? 2.4.2.0 >> parallel: 3.2.0.3 ? 3.2.0.4 >> syb: 0.4.0 ? 0.4.1 >> unordered-containers: 0.2.3.0 ? 0.2.3.3 >> vector: 0.10.0.1 ? 0.10.9.1? >> primitive: 0.5.0.1 ? 0.5.1.0? >> >> *Packages with major version bumps:* >> *I'd like to get confirmation from the maintainers of these packages that >> this bump is "the right thing to do". The bump should ideally only add API, >> and not orphan any program that used to compile under the HP - at least not >> without a good reason.* >> case-insensitive: 1.0.0.1 ? 1.1.0.1 >> hashable: 1.1.2.5 ? 1.2.1.0 >> >> GLUT: 2.4.0.0 ? 2.5.0.1 >> GLURaw: 1.3.0.0 ? 1.4.0.0 >> OpenGL: 2.8.0.0 ? 2.9.1.0 >> OpenGLRaw: 1.3.0.0 ? 1.4.0.0 >> >> alex: 3.0.5 ? 3.1.0 >> happy: 1.18.10 ? 1.19.0 >> >> *New Packages:* >> *There was prior discussion on the libraries mailing list, and generally >> all around resounding "YES!" for including aeson.* >> *I think we should include it. I'm looking for confirmation from the >> maintainer that this is the right version to include.* >> aeson: 0.6.2.1 >> >> *Cabal:* >> *The Cabal 1.18 release was a major new release, including the very very >> useful sandbox feature. This would require shipping a different Cabal lib >> than the version shipped with the included GHC. I'm not sure of the >> implications of doing this - in particular, whether we would have to ship >> two Cabal packages or just the later.* >> Cabal: 1.16.0 ? 1.18.1.2 >> cabal-install: 1.16.0.2 ? 1.18.0.2 >> >> What do you all think? >> >> ? Mark "late, but not forgotten" Lentczner >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries -- shelarcy http://page.freett.com/shelarcy/ From mail at joachim-breitner.de Mon Nov 11 08:34:21 2013 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 11 Nov 2013 09:34:21 +0100 Subject: 2013.4.0.0 proposal In-Reply-To: References: Message-ID: <1384158861.2370.0.camel@kirk> Hi, Am Sonntag, den 10.11.2013, 08:11 -0800 schrieb Mark Lentczner: > Cabal: > The Cabal 1.18 release was a major new release, including the very > very useful sandbox feature. This would require shipping a different > Cabal lib than the version shipped with the included GHC. I'm not sure > of the implications of doing this - in particular, whether we would > have to ship two Cabal packages or just the later. > Cabal: 1.16.0 ? 1.18.1.2 > cabal-install: 1.16.0.2 ? 1.18.0.2 the Debian ghc package ships Cabal, and necessarily the version that comes with GHC. We could introduce a separate haskell-cabal package, but I?m also unsure about the implications, so I have been flinching from uploading Cabal-1.18 to Debian. I?d feel more comfortable with this boot-library version deviation if someone who knows the interaction of GHC (the compiler), ghc (the librarY) and Cabal better can comment on it. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From v.dijk.bas at gmail.com Mon Nov 11 09:16:37 2013 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Mon, 11 Nov 2013 10:16:37 +0100 Subject: 2013.4.0.0 proposal In-Reply-To: References: Message-ID: The case-insensitive bump is good. From v.dijk.bas at gmail.com Mon Nov 11 10:07:49 2013 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Mon, 11 Nov 2013 11:07:49 +0100 Subject: 2013.4.0.0 proposal In-Reply-To: References: Message-ID: On 10 November 2013 23:14, Mark Lentczner wrote: > I spoke too soon: > > aeson induces blaze-builder Note that I removed the blaze-builder requirement from aeson-HEAD (it now uses the Builder from bytestring with a fallback to blaze-builder when configured with -fblaze-builder). I think we're pretty close to a release of aeson-0.7.0.0. It would be great to have this version in the HP since: * It includes an important bug fix for the eitherDecodeStrict functions. * It has support for arbitrary precision floating point numbers (as required by the JSON spec) through the Scientific type. * It removes the ByteString instances since JSON doesn't have support for binary data (this was brought up during the HP inclusion discussion). * It adds ToJSON and FromJSON for Data.Tree. Bas From allbery.b at gmail.com Mon Nov 11 14:42:51 2013 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 11 Nov 2013 09:42:51 -0500 Subject: 2013.4.0.0 proposal In-Reply-To: <1384158861.2370.0.camel@kirk> References: <1384158861.2370.0.camel@kirk> Message-ID: On Mon, Nov 11, 2013 at 3:34 AM, Joachim Breitner wrote: > I?d feel more comfortable with this boot-library version deviation if > someone who knows the interaction of GHC (the compiler), ghc (the > librarY) and Cabal better can comment on it. > I can't say I know the full details of the interactions, but the Cabal library is essentially the only bootlib that not only can safely (I don't think I've ever heard of anyone getting into trouble) be upgraded, but often is *recommended* for upgrade to support newer cabal-install. I think this is because ghc only uses a small portion of it that has been stable for a long time (avoiding data incompatibility) and it's compiled in (so no link time strangeness). The only issues that come to mind would be if someone were to write TH that itself explicitly called out to Cabal, or maybe some complex ghc-as-a-library stuff in a program explicitly using Cabal itself. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwlato at gmail.com Mon Nov 11 16:15:49 2013 From: jwlato at gmail.com (John Lato) Date: Mon, 11 Nov 2013 10:15:49 -0600 Subject: 2013.4.0.0 proposal In-Reply-To: References: <1384158861.2370.0.camel@kirk> Message-ID: On Nov 11, 2013 8:43 AM, "Brandon Allbery" wrote: > > > On Mon, Nov 11, 2013 at 3:34 AM, Joachim Breitner < mail at joachim-breitner.de> wrote: >> >> I?d feel more comfortable with this boot-library version deviation if >> someone who knows the interaction of GHC (the compiler), ghc (the >> librarY) and Cabal better can comment on it. > > > I can't say I know the full details of the interactions, but the Cabal library is essentially the only bootlib that not only can safely (I don't think I've ever heard of anyone getting into trouble) be upgraded, but often is *recommended* for upgrade to support newer cabal-install. I think this is because ghc only uses a small portion of it that has been stable for a long time (avoiding data incompatibility) and it's compiled in (so no link time strangeness). The only issues that come to mind would be if someone were to write TH that itself explicitly called out to Cabal, or maybe some complex ghc-as-a-library stuff in a program explicitly using Cabal itself. TBH I don't see how even those cases would cause a problem. I think a more likely situation would be a user installing a package that depends on the boot-lib install, then have that package be incompatible with everything else. But even that seems fairly rare. John L. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dag.odenhall at gmail.com Mon Nov 11 16:19:25 2013 From: dag.odenhall at gmail.com (Dag Odenhall) Date: Mon, 11 Nov 2013 17:19:25 +0100 Subject: 2013.4.0.0 proposal In-Reply-To: References: Message-ID: Wouldn?t it be trivial to get rid of the dlist dependency using Endoinstead, too? It seems to only be an implementation detail. On the other hand, maybe dlist in Platform makes sense anyway. On Mon, Nov 11, 2013 at 11:07 AM, Bas van Dijk wrote: > On 10 November 2013 23:14, Mark Lentczner > wrote: > > I spoke too soon: > > > > aeson induces blaze-builder > > Note that I removed the blaze-builder requirement from aeson-HEAD (it > now uses the Builder from bytestring with a fallback to blaze-builder > when configured with -fblaze-builder). > > I think we're pretty close to a release of aeson-0.7.0.0. It would be > great to have this version in the HP since: > > * It includes an important bug fix for the eitherDecodeStrict functions. > > * It has support for arbitrary precision floating point numbers (as > required by the JSON spec) through the Scientific type. > > * It removes the ByteString instances since JSON doesn't have support > for binary data (this was brought up during the HP inclusion > discussion). > > * It adds ToJSON and FromJSON for Data.Tree. > > Bas > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwlato at gmail.com Mon Nov 11 16:30:34 2013 From: jwlato at gmail.com (John Lato) Date: Mon, 11 Nov 2013 10:30:34 -0600 Subject: 2013.4.0.0 proposal In-Reply-To: References: Message-ID: This is true, and in fact I almost never use dlist myself (or Endo), since lambdas are already quite light weight. However, dlist makes the intention explicit, which is probably a good enough reason to use it in a package in the platform. On Nov 11, 2013 10:20 AM, "Dag Odenhall" wrote: > Wouldn?t it be trivial to get rid of the dlist dependency using Endoinstead, too? It seems to only be an implementation detail. On the other > hand, maybe dlist in Platform makes sense anyway. > > > On Mon, Nov 11, 2013 at 11:07 AM, Bas van Dijk wrote: > >> On 10 November 2013 23:14, Mark Lentczner >> wrote: >> > I spoke too soon: >> > >> > aeson induces blaze-builder >> >> Note that I removed the blaze-builder requirement from aeson-HEAD (it >> now uses the Builder from bytestring with a fallback to blaze-builder >> when configured with -fblaze-builder). >> >> I think we're pretty close to a release of aeson-0.7.0.0. It would be >> great to have this version in the HP since: >> >> * It includes an important bug fix for the eitherDecodeStrict functions. >> >> * It has support for arbitrary precision floating point numbers (as >> required by the JSON spec) through the Scientific type. >> >> * It removes the ByteString instances since JSON doesn't have support >> for binary data (this was brought up during the HP inclusion >> discussion). >> >> * It adds ToJSON and FromJSON for Data.Tree. >> >> Bas >> _______________________________________________ >> 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 ganesh at earth.li Tue Nov 12 08:21:04 2013 From: ganesh at earth.li (Ganesh Sittampalam) Date: Tue, 12 Nov 2013 08:21:04 +0000 Subject: 2013.4.0.0 proposal In-Reply-To: References: Message-ID: <5281E4F0.3030301@earth.li> On 10/11/2013 16:11, Mark Lentczner wrote: > *Packages with no changes:* > HTTP [..] > case-insensitive: 1.0.0.1 ? 1.1.0.1 FYI I've just uploaded HTTP 4000.2.9 which just has some dependency bumps. Might be worth adding moving to this as there's a case-insensitive dependency in the test suite which is now compatible with the new Platform version, but as it's only the test suite and the previous Platform didn't have them matching up, it's not very important. Ganesh From v.dijk.bas at gmail.com Tue Nov 12 08:26:57 2013 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Tue, 12 Nov 2013 09:26:57 +0100 Subject: 2013.4.0.0 proposal In-Reply-To: References: Message-ID: On 10 November 2013 22:40, Mark Lentczner wrote: > Including aeson, which I think we'd all very much like to do, requires > dlist-0.5. > Now, dlist has been around for a very long time, and is very stable. > I do not believe that dlist's API is exposed indirectly via aeson at all. > > I hereby propose that it be added to the platform. > At the very least, it could be like primitive - in the platform, but not > "part" of it. > > Thoughts? +1 However, note that I don't mind dropping the dlist dependency from aeson. I use it in a very limited internal place: https://github.com/bos/aeson/blob/master/Data/Aeson/Types/Generic.hs#L213 Don, If we do decide to include dlist in the HP it would be great if the following instances can be added to it: instance Alternative DList where empty = empty (<|>) = append instance Eq a => Eq (DList a) where (==) = (==) `on` toList instance Ord a => Ord (DList a) where compare = compare `on` toList instance Show a => Show (DList a) where showsPrec p dl = showParen (p >= 10) $ showString "Data.DList.fromList " . shows (toList dl) Bas From sean.leather at gmail.com Tue Nov 12 10:47:45 2013 From: sean.leather at gmail.com (Sean Leather) Date: Tue, 12 Nov 2013 12:47:45 +0200 Subject: 2013.4.0.0 proposal In-Reply-To: References: Message-ID: > On 10 November 2013 22:40, Mark Lentczner > wrote: > > Including aeson, which I think we'd all very much like to do, requires > > dlist-0.5. > > Now, dlist has been around for a very long time, and is very stable. > > I do not believe that dlist's API is exposed indirectly via aeson at all. > > > > I hereby propose that it be added to the platform. > > At the very least, it could be like primitive - in the platform, but not > > "part" of it. > > > > Thoughts? > Considering the somewhat fundamental nature of dlist, I think it would be appropriate to have in the platform. On Tue, Nov 12, 2013 at 10:26 AM, Bas van Dijk wrote: > However, note that I don't mind dropping the dlist dependency from > aeson. I use it in a very limited internal place: > > https://github.com/bos/aeson/blob/master/Data/Aeson/Types/Generic.hs#L213 > > Don, If we do decide to include dlist in the HP it would be great if > the following instances can be added to it: > Assuming Don is willing and others agree, I don't mind taking over maintenance of dlist. I just imported it into GitHub: https://github.com/spl/dlist Bas: please submit a pull request with the suggested changes. They all look good. Regards, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.dijk.bas at gmail.com Tue Nov 12 12:52:03 2013 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Tue, 12 Nov 2013 13:52:03 +0100 Subject: 2013.4.0.0 proposal In-Reply-To: References: Message-ID: On 12 November 2013 11:47, Sean Leather wrote: > Assuming Don is willing and others agree, I don't mind taking over > maintenance of dlist. I just imported it into GitHub: > https://github.com/spl/dlist Thanks for maintaining it! > Bas: please submit a pull request with the suggested changes. They all look > good. Done: https://github.com/spl/dlist/pull/1 Bas From mail at joachim-breitner.de Wed Nov 13 17:53:33 2013 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 13 Nov 2013 18:53:33 +0100 Subject: 2013.4.0.0 proposal In-Reply-To: References: Message-ID: <1384365213.14833.4.camel@kirk> Hi, Am Dienstag, den 12.11.2013, 09:26 +0100 schrieb Bas van Dijk: > On 10 November 2013 22:40, Mark Lentczner wrote: > > Including aeson, which I think we'd all very much like to do, requires > > dlist-0.5. > > Now, dlist has been around for a very long time, and is very stable. > > I do not believe that dlist's API is exposed indirectly via aeson at all. > > > > I hereby propose that it be added to the platform. > > At the very least, it could be like primitive - in the platform, but not > > "part" of it. > > > > Thoughts? > > +1 > > However, note that I don't mind dropping the dlist dependency from > aeson. I use it in a very limited internal place: > > https://github.com/bos/aeson/blob/master/Data/Aeson/Types/Generic.hs#L213 while dlist is certainly a nice and stable library, it is still relatively specialized, and I would personally not consider it important enough to be included in the platform. I?d like the platform to stay a selection of packages that people not only can use, but really should know about, and use them instead of rolling their own. I?m not sure if this holds for dlist ? using [a] -> [a] and (.) directly is also good practice. My suggestion is to remove it from aeson, and keep the platform small and focused. Greetings, Joachim -- Joachim Breitner e-Mail: mail at joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nomeata at joachim-breitner.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From v.dijk.bas at gmail.com Wed Nov 13 18:10:41 2013 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Wed, 13 Nov 2013 19:10:41 +0100 Subject: 2013.4.0.0 proposal In-Reply-To: <1384365213.14833.4.camel@kirk> References: <1384365213.14833.4.camel@kirk> Message-ID: On 13 Nov 2013 18:53, "Joachim Breitner" wrote: > > Hi, > > Am Dienstag, den 12.11.2013, 09:26 +0100 schrieb Bas van Dijk: > > On 10 November 2013 22:40, Mark Lentczner wrote: > > > Including aeson, which I think we'd all very much like to do, requires > > > dlist-0.5. > > > Now, dlist has been around for a very long time, and is very stable. > > > I do not believe that dlist's API is exposed indirectly via aeson at all. > > > > > > I hereby propose that it be added to the platform. > > > At the very least, it could be like primitive - in the platform, but not > > > "part" of it. > > > > > > Thoughts? > > > > +1 > > > > However, note that I don't mind dropping the dlist dependency from > > aeson. I use it in a very limited internal place: > > > > https://github.com/bos/aeson/blob/master/Data/Aeson/Types/Generic.hs#L213 > > while dlist is certainly a nice and stable library, it is still > relatively specialized, and I would personally not consider it important > enough to be included in the platform. I?d like the platform to stay a > selection of packages that people not only can use, but really should > know about, and use them instead of rolling their own. I?m not sure if > this holds for dlist ? using [a] -> [a] and (.) directly is also good > practice. Hi Joachim, I would call using [a] -> [a] and (.): "rolling your own" and I consider it bad practise. Code would be easier to understand if it used common names. > My suggestion is to remove it from aeson, and keep the platform small > and focused. I think its best if I remove dlist from aeson and that we discuss its inclusion into the HP (after next) in a separate proposal. Sean: care to lead the proposal? Bas -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at scientician.net Wed Nov 13 18:17:25 2013 From: spam at scientician.net (Bardur Arantsson) Date: Wed, 13 Nov 2013 19:17:25 +0100 Subject: 2013.4.0.0 proposal In-Reply-To: References: <1384365213.14833.4.camel@kirk> Message-ID: On 2013-11-13 19:10, Bas van Dijk wrote: > I think its best if I remove dlist from aeson and that we discuss its > inclusion into the HP (after next) in a separate proposal. +1. It's not so much that dlist is "bad" or anything, but it's more that dependencies (of any kind) have a non-trivial cost considering that that Haskell modules are currently IMD and not SMD. (See the very interesting paper here: http://plv.mpi-sws.org/backpack/index.html). Regards, From mail at joachim-breitner.de Wed Nov 13 18:20:54 2013 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 13 Nov 2013 19:20:54 +0100 Subject: 2013.4.0.0 proposal In-Reply-To: References: <1384365213.14833.4.camel@kirk> Message-ID: <1384366854.14833.9.camel@kirk> [taking this off the platform mailing list] Hi, Am Mittwoch, den 13.11.2013, 19:10 +0100 schrieb Bas van Dijk: > I would call using [a] -> [a] and (.): "rolling your own" and I > consider it bad practise. Code would be easier to understand if it > used common names. I?m not sure; there is a concept behind it that applied to other data types as well, e.g. trees, possibly defined by the user. Having people knowledgeable about [a] -> [a] will enable them to apply the same pattern to their own data types. If [a] -> [a] were bad practice, then base should stop using it?, and Data.DList should become part of base. (This is not a strawman argument: If people support this then sure, why not). One main advantage of dlist if of course that it comes with instances (Monad, Functor, etc.) Greetings, Joachim ? http://hackage.haskell.org/package/base-4.6.0.1/docs/Prelude.html#t:ShowS -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From mark.lentczner at gmail.com Wed Nov 13 19:33:37 2013 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Wed, 13 Nov 2013 11:33:37 -0800 Subject: 2013.4.0.0 proposal In-Reply-To: References: Message-ID: I'd like to better understand the backwards compatibility of these changes, and this new major bump of aeson: On Mon, Nov 11, 2013 at 2:07 AM, Bas van Dijk wrote: > Note that I removed the blaze-builder requirement from aeson-HEAD (it > now uses the Builder from bytestring with a fallback to blaze-builder > when configured with -fblaze-builder). > Which we'd have to do for this HP, as the bytestring package is 0.10.0.2 from the GHC release. Hence, the blaze-builder requirement would still be there. > I think we're pretty close to a release of aeson-0.7.0.0. It would be > great to have this version in the HP since: > I'm concerned about timing. In particular, how long should a new major version bump release be out before one is confident that it won't need a minor rev. (0.7.0.1) soon? > * It includes an important bug fix for the eitherDecodeStrict functions Well, that seems good. Could that get back ported on top of 0.6.2.1 if we decided to not do a major bump this time? > * It has support for arbitrary precision floating point numbers (as required by the JSON spec) through the Scientific type. > Well, one can argue if that is what the spec says - but in practice, JSON libraries in other systems don't use arbitrary precision floating point (nor does any JavaScript implementation that I know of). Those issues aside, how does the API evolve? What is the plan for introducing this functionality without breaking existing aeson relying code? aeson's Number constructor points to Number from attoparsec which has only two constructors: I Integer and D Double. Wouldn't introducing a third, or replacing D, break existing uses of aeson? * It removes the ByteString instances since JSON doesn't have support > for binary data (this was brought up during the HP inclusion > discussion). > Do we have any usage stats to know if any code uses this show instance? Again, trying to avoid breaking compiling code. Were deprecation notices added to the package at some point? - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Wed Nov 13 19:33:44 2013 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Wed, 13 Nov 2013 11:33:44 -0800 Subject: 2013.4.0.0 proposal In-Reply-To: <5281E4F0.3030301@earth.li> References: <5281E4F0.3030301@earth.li> Message-ID: On Tue, Nov 12, 2013 at 12:21 AM, Ganesh Sittampalam wrote: > FYI I've just uploaded HTTP 4000.2.9 which just has some dependency bumps. Okay, I'll bump to this version. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Wed Nov 13 19:48:54 2013 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Wed, 13 Nov 2013 11:48:54 -0800 Subject: 2013.4.0.0 proposal In-Reply-To: <1384365213.14833.4.camel@kirk> References: <1384365213.14833.4.camel@kirk> Message-ID: Re dlist The platform hasn't been aiming for "small and focused" for quite some time. And last year I called for a significant expansion of the palatform, and this was met with general enthusiasm. The original motto for the platform: "batteries included" is still apt. We want to the platform to provide, out-of-the-box, a broad selection of packages for common computing needs, where these packages can be counted on to be there, to be stable, and be a reasonable default choice - and hence worth learning and keeping in your toolbox. Not every package has to be "the only best way" to do some task - Python includes a default HTTP server, but there are plenty of others out there, and good reasons to choose them. We want packages to be the reasonable default to turn to, when the choice doesn't warrant researching through alternative packages on hackage, or soliciting opinions on IRC. Of course, the transitive nature of packages in the platform means that sometime we have things in there that don't quite live up to those goals. primitive is in the platform because vector needs it... but it isn't quite a common computing need. Dlist probably wouldn't have made it in on it's own merits - but it isn't bad, and certainly a reasonable way to do what it does if that is what you need and just want to get on with whatever else your doing. (perhaps our motto should be "less yak-shaving"!) Since the use of Dlist isn't exposed in aeson's interface , it could go either way. But I think it would be reasonable to include. - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.tetley at gmail.com Wed Nov 13 22:34:58 2013 From: stephen.tetley at gmail.com (Stephen Tetley) Date: Wed, 13 Nov 2013 22:34:58 +0000 Subject: 2013.4.0.0 proposal In-Reply-To: <1384366854.14833.9.camel@kirk> References: <1384365213.14833.4.camel@kirk> <1384366854.14833.9.camel@kirk> Message-ID: On 13 November 2013 18:20, Joachim Breitner wrote: > One main advantage of dlist if of course that it comes with instances > (Monad, Functor, etc.) I consider these instances a disadvantage of DList as you have to metamorph via a List to use them. As this isn't germane to the debate, though, I'll crawl back under my stone. From v.dijk.bas at gmail.com Wed Nov 13 22:37:10 2013 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Wed, 13 Nov 2013 23:37:10 +0100 Subject: 2013.4.0.0 proposal In-Reply-To: References: Message-ID: On 13 Nov 2013 20:33, "Mark Lentczner" wrote: > > I'd like to better understand the backwards compatibility of these changes, and this new major bump of aeson: My idea for the new major release aeson-0.7 was that it would be included in the next HP and introduce breaking changes but that it would significantly stabilize after this. I would prefer this over first including and old release and then later including a breaking release since I would like the HP to be as stable as possible. > On Mon, Nov 11, 2013 at 2:07 AM, Bas van Dijk wrote: >> >> Note that I removed the blaze-builder requirement from aeson-HEAD (it >> now uses the Builder from bytestring with a fallback to blaze-builder >> when configured with -fblaze-builder). > > > Which we'd have to do for this HP, as the bytestring package is 0.10.0.2 from the GHC release. Hence, the blaze-builder requirement would still be there. It seems bytestring-0.10.0.2 provides a Builder: http://hackage.haskell.org/package/bytestring-0.10.0.2 >> >> I think we're pretty close to a release of aeson-0.7.0.0. It would be >> great to have this version in the HP since: > > > I'm concerned about timing. In particular, how long should a new major version bump release be out before one is confident that it won't need a minor rev. (0.7.0.1) soon? > >> >> * It includes an important bug fix for the eitherDecodeStrict functions > > > Well, that seems good. Could that get back ported on top of 0.6.2.1 if we decided to not do a major bump this time? That won't be difficult. >> >> * It has support for arbitrary precision floating point numbers (as >> >> required by the JSON spec) through the Scientific type. > > > Well, one can argue if that is what the spec says - but in practice, JSON libraries in other systems don't use arbitrary precision floating point (nor does any JavaScript implementation that I know of). True. However, users also might want to send arbitrary precision numbers as JSON between two Haskell systems using aeson. Also the Scientific type proved to be more efficient to parse. > Those issues aside, how does the API evolve? What is the plan for introducing this functionality without breaking existing aeson relying code? aeson's Number constructor points to Number from attoparsec which has only two constructors: I Integer and D Double. Wouldn't introducing a third, or replacing D, break existing uses of aeson? aeson-0.7 will break code that is directly constructing or analyzing the Number type from the Number constructor from the Value type since that will change to the Scientific number type. I expect that there isn't that many code like that since for decoding or encoding directly to standard numeric types users are probably using the provided FromJSON and ToJSON instances which will keep working as they were. For users that do need to use the Number constructor from the Value type they can still use the (deprecated) withNumber function for parsing. For construction I expect most of these users to use the standard numeric conversion functions like fromInteger, fromIntegral or realToFrac which should work unmodified for Scientific values. >> * It removes the ByteString instances since JSON doesn't have support >> for binary data (this was brought up during the HP inclusion >> discussion). > > > Do we have any usage stats to know if any code uses this show instance? No we don't and I agree this would be useful to have but probably hard the obtain. > Again, trying to avoid breaking compiling code. Were deprecation notices added to the package at some point? I don't think you can add deprecation pragma's to instances which is unfortunate. Thanks for doing this due diligence Mark! Bas -------------- next part -------------- An HTML attachment was scrubbed... URL: From dluposchainsky at googlemail.com Thu Nov 14 23:03:35 2013 From: dluposchainsky at googlemail.com (David Luposchainsky) Date: Fri, 15 Nov 2013 00:03:35 +0100 Subject: Proposal: Expand TBQueue API with 'currentSize' Message-ID: <528556C7.804@gmail.com> Hey everyone, Concurrent channels are very opaque right now: all that can be done is checking they're empty. The upcoming release will, thanks to Merijn, contain a way of checking whether a TBQueue is full. However, there may be scenarios where it is desirable to retrieve the current size of a TBQueue. The reason I mention TBQueue specifically is because it already contains said information, but does not export corresponding accessor functions, so the implementation would be fairly easy. Probably the most compelling use case I can think of is debugging. Sometimes "full" or "empty" just isn't enough: it may be useful at which point in time the queue starts being filled disproportionately. (I just had a case where I could have saved many hours.) Another one inspired by someone on #haskell a couple of minutes ago is when a "size moderated" queue is desirable, i.e. one that is usually somewhat filled but still allows being written to in important cases. The specific example given was a device sending data through a channel where the input can be throttled based on how fast the output ends process the data. The code would be simply the following: > lengthTBQueue :: TBQueue a -> STM Int > lengthTBQueue (TBQueue rsize _read wsize _write) = readTVar rsize Another possible addition would be retrieving a TBQueue's maximum size. Although this has to be known in order to create the queue in the first place, when the queue is used deep down in other functions passing the size explicitly as a parameter seems a little unnecessary. David/quchen From hvr at gnu.org Sun Nov 17 08:39:07 2013 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Sun, 17 Nov 2013 09:39:07 +0100 Subject: Proposal: Add `instance Bits Bool` In-Reply-To: (Edward Kmett's message of "Sun, 10 Nov 2013 23:33:31 +0100") References: Message-ID: <87li0n2zis.fsf@gnu.org> On 2013-11-10 at 23:33:31 +0100, Edward Kmett wrote: > We went through all the pain of removing Num as a superclass of Bits to > support it, but we apparently never actually put the instance of Bits (and > FiniteBits) for Bool into base. > I propose we do so. +1 From mark.lentczner at gmail.com Sun Nov 17 19:55:27 2013 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sun, 17 Nov 2013 11:55:27 -0800 Subject: 2013.4.0.0 proposal - getting to alpha Message-ID: Here is the current status of the 2013.4.0.0 proposal. *Outstanding Issues* We have a few decisions outstanding, and I'd like to have these decided by Nov. 23 (one week). - fgl - waiting to hear if Ivan will have new version ready in time. - aeson / dlist - there are serveral options -- I'll start a separate thread on this topic. - alex / happy - I'd like to hear an "okay" from the maintainers on the major version bump *Current Proposed Versions* *GHC 7.6.3* -- same as last time (erroneously listed as a version bump last time) *Packages with no changes:* fgl, haskell-src, html, HUnit, mtl, parsec, QuickCheck, random, regex-base, regex-compat, regex-posix, split, stm, text, transformers, xhtml, zlib *Packages held back:* cgi: 3001.1.7.5 (3001.1.8.4* requires MonadCatchIO-mtl)* *Packages with minor version bumps:* HTTP: 4000.2.8 ? 4000.2.9 network: 2.4.1.2 ? 2.4.2.0 parallel: 3.2.0.3 ? 3.2.0.4 syb: 0.4.0 ? 0.4.1 unordered-containers: 0.2.3.0 ? 0.2.3.3 vector: 0.10.0.1 ? 0.10.9.1? primitive: 0.5.0.1 ? 0.5.1.0? *Packages with major version bumps:* case-insensitive: 1.0.0.1 ? 1.1.0.1 hashable: 1.1.2.5 ? 1.2.1.0 GLUT: 2.4.0.0 ? 2.5.0.1 GLURaw: 1.3.0.0 ? 1.4.0.0 OpenGL: 2.8.0.0 ? 2.9.1.0 OpenGLRaw: 1.3.0.0 ? 1.4.0.0 alex: 3.0.5 ? 3.1.0 *pending okay* happy: 1.18.10 ? 1.19.0 *pending okay* *Cabal:* Cabal: 1.16.0 ? 1.18.1.2 *consensus seems to be that this will be okay* cabal-install: 1.16.0.2 ? 1.18.0.2 *Platform Packagers:* This is likely to be the last HP source release that contains all the ad hoc scripts for packaging. I canvased the group last time and as I recall, everyone said they just used the .cabal file - and no one used the scripts. I plan to replace them with a new tool built for the needs of the release, and ditch this old set of scripts. If you need 'em, speak now, or forever hold your peace! ? Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Sun Nov 17 20:20:57 2013 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sun, 17 Nov 2013 12:20:57 -0800 Subject: aeson and dlist in HP 2013.4.0.0 Message-ID: We seem to have several interlocking decisions to make about *aeson* and *dlist* in the platform: *Background:* *let me know if I got any of this wrong* - There is clear agreement to have *aeson* in the platform. - *aeson* 0.6.2.1 would require *dlist* & *blaze-builder* to be added. - There is a patch to *aeson*, already in head, that makes *aeson* use the builder in *bytestring*, and drop the dependency on *blaze-builder*. This is good, as a *bytestring* in GHC 7.8 will make *blaze-builder*obsolete. - *aeson* head uses a new Scientific type for arbitrary precision floating point. This will break users of the Number constructor of the Value type. However, it is believed that most users are probably using existing functions to parse to an from standard numeric types when needed, and those continue to work. Unclear how much impact this will have. Also, Scientific could be in it's own package (which would need to be added to the platform), or simply exposed from *aeson*. - *dlist* is stable, but could use some love - which was lovingly offered, and we could have a bump which adds some useful typeclass instances. - It was noted that *dlist* could be replaced by Endo, or explicit use of simple types. There didn't seem to be much support for the idea of altering *aeson* to do so. *Options for aeson:* 1. skip it in this release 2. include *aeson* 0.6.2.1 - requiring both *dlist* and *blaze-builder* 3. include *aeson* 0.6.2.x, a version with the patch that uses *bytestring*'s builder, and so require only *dlist* 4. include *aeson* 0.7.0.0 - requiring *dlist* and possibly *scientific* *Options for dlist, if required by the aeson choice, or because we now like it anyway:* 1. include *dlist* 0.5 2. include *dlist* 0.6, with new typeclass instances added *Options for scientific, if required by the aeson choice:* 1. include Scientific type in *aeson* 2. include a new *scientific* pacakge *Discussion:* I think the best option, if we are ready to embrace aeson, is jump in with both feet: aeson 0.7.0.0, & dlist 0.6. Leaving the issue of is scientific ready to be included as it's own package, or should it just be exported by aeson for now. Thoughts? ? Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sun Nov 17 20:25:28 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 17 Nov 2013 15:25:28 -0500 Subject: 2013.4.0.0 proposal - getting to alpha In-Reply-To: References: Message-ID: There's currently an issue with Alex happy when they're built with clang cpp rather Than GCC cpp which some folks are trying to hammer out I think. I think it's a problem in Alex 3.1.2 but not 3.1.0. Either way: assuming that bug gets sorted out, making sure Haskell platform has a fresher Alex / happy so that Haskell platform can be used to build ghc 7.8 would be a nice thing to have. On Sunday, November 17, 2013, Mark Lentczner wrote: > Here is the current status of the 2013.4.0.0 proposal. > > *Outstanding Issues* > We have a few decisions outstanding, and I'd like to have these decided by > Nov. 23 (one week). > > - fgl - waiting to hear if Ivan will have new version ready in time. > - aeson / dlist - there are serveral options -- I'll start a separate > thread on this topic. > - alex / happy - I'd like to hear an "okay" from the maintainers on > the major version bump > > > *Current Proposed Versions* > *GHC 7.6.3* -- same as last time (erroneously listed as a version bump > last time) > > *Packages with no changes:* > fgl, haskell-src, html, HUnit, > mtl, parsec, QuickCheck, random, > regex-base, regex-compat, regex-posix, > split, stm, text, transformers, > xhtml, zlib > > *Packages held back:* > cgi: 3001.1.7.5 (3001.1.8.4* requires MonadCatchIO-mtl)* > > *Packages with minor version bumps:* > HTTP: 4000.2.8 ? 4000.2.9 > network: 2.4.1.2 ? 2.4.2.0 > parallel: 3.2.0.3 ? 3.2.0.4 > syb: 0.4.0 ? 0.4.1 > unordered-containers: 0.2.3.0 ? 0.2.3.3 > vector: 0.10.0.1 ? 0.10.9.1? > primitive: 0.5.0.1 ? 0.5.1.0? > > *Packages with major version bumps:* > case-insensitive: 1.0.0.1 ? 1.1.0.1 > hashable: 1.1.2.5 ? 1.2.1.0 > > GLUT: 2.4.0.0 ? 2.5.0.1 > GLURaw: 1.3.0.0 ? 1.4.0.0 > OpenGL: 2.8.0.0 ? 2.9.1.0 > OpenGLRaw: 1.3.0.0 ? 1.4.0.0 > > alex: 3.0.5 ? 3.1.0 *pending okay* > happy: 1.18.10 ? 1.19.0 *pending okay* > > *Cabal:* > Cabal: 1.16.0 ? 1.18.1.2 *consensus seems to be that this will be > okay* > cabal-install: 1.16.0.2 ? 1.18.0.2 > > > *Platform Packagers:* > This is likely to be the last HP source release that contains all the ad > hoc scripts for packaging. I canvased the group last time and as I recall, > everyone said they just used the .cabal file - and no one used the scripts. > I plan to replace them with a new tool built for the needs of the release, > and ditch this old set of scripts. If you need 'em, speak now, or forever > hold your peace! > > ? Mark > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From conrad at metadecks.org Sun Nov 17 21:44:41 2013 From: conrad at metadecks.org (Conrad Parker) Date: Mon, 18 Nov 2013 08:44:41 +1100 Subject: Proposal: Add `instance Bits Bool` In-Reply-To: <87li0n2zis.fsf@gnu.org> References: <87li0n2zis.fsf@gnu.org> Message-ID: On 17 November 2013 19:39, Herbert Valerio Riedel wrote: > On 2013-11-10 at 23:33:31 +0100, Edward Kmett wrote: > > We went through all the pain of removing Num as a superclass of Bits to > > support it, but we apparently never actually put the instance of Bits > (and > > FiniteBits) for Bool into base. > > > I propose we do so. > > +1 > +1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon Nov 18 03:26:39 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 17 Nov 2013 22:26:39 -0500 Subject: 2013.4.0.0 proposal - getting to alpha In-Reply-To: References: Message-ID: looks like theres a candidate patch for the alex issue by Nick Partridge https://github.com/simonmar/alex/pull/37 On Sun, Nov 17, 2013 at 3:25 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > There's currently an issue with Alex happy when they're built with clang > cpp rather Than GCC cpp which some folks are trying to hammer out I think. > I think it's a problem in Alex 3.1.2 but not 3.1.0. > > Either way: assuming that bug gets sorted out, making sure Haskell > platform has a fresher Alex / happy so that Haskell platform can be used to > build ghc 7.8 would be a nice thing to have. > > > On Sunday, November 17, 2013, Mark Lentczner wrote: > >> Here is the current status of the 2013.4.0.0 proposal. >> >> *Outstanding Issues* >> We have a few decisions outstanding, and I'd like to have these decided >> by Nov. 23 (one week). >> >> - fgl - waiting to hear if Ivan will have new version ready in time. >> - aeson / dlist - there are serveral options -- I'll start a separate >> thread on this topic. >> - alex / happy - I'd like to hear an "okay" from the maintainers on >> the major version bump >> >> >> *Current Proposed Versions* >> *GHC 7.6.3* -- same as last time (erroneously listed as a version bump >> last time) >> >> *Packages with no changes:* >> fgl, haskell-src, html, HUnit, >> mtl, parsec, QuickCheck, random, >> regex-base, regex-compat, regex-posix, >> split, stm, text, transformers, >> xhtml, zlib >> >> *Packages held back:* >> cgi: 3001.1.7.5 (3001.1.8.4* requires MonadCatchIO-mtl)* >> >> *Packages with minor version bumps:* >> HTTP: 4000.2.8 ? 4000.2.9 >> network: 2.4.1.2 ? 2.4.2.0 >> parallel: 3.2.0.3 ? 3.2.0.4 >> syb: 0.4.0 ? 0.4.1 >> unordered-containers: 0.2.3.0 ? 0.2.3.3 >> vector: 0.10.0.1 ? 0.10.9.1? >> primitive: 0.5.0.1 ? 0.5.1.0? >> >> *Packages with major version bumps:* >> case-insensitive: 1.0.0.1 ? 1.1.0.1 >> hashable: 1.1.2.5 ? 1.2.1.0 >> >> GLUT: 2.4.0.0 ? 2.5.0.1 >> GLURaw: 1.3.0.0 ? 1.4.0.0 >> OpenGL: 2.8.0.0 ? 2.9.1.0 >> OpenGLRaw: 1.3.0.0 ? 1.4.0.0 >> >> alex: 3.0.5 ? 3.1.0 *pending okay* >> happy: 1.18.10 ? 1.19.0 *pending okay* >> >> *Cabal:* >> Cabal: 1.16.0 ? 1.18.1.2 *consensus seems to be that this will >> be okay* >> cabal-install: 1.16.0.2 ? 1.18.0.2 >> >> >> *Platform Packagers:* >> This is likely to be the last HP source release that contains all the ad >> hoc scripts for packaging. I canvased the group last time and as I recall, >> everyone said they just used the .cabal file - and no one used the scripts. >> I plan to replace them with a new tool built for the needs of the release, >> and ditch this old set of scripts. If you need 'em, speak now, or forever >> hold your peace! >> >> ? Mark >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Mon Nov 18 05:49:26 2013 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sun, 17 Nov 2013 21:49:26 -0800 Subject: 2013.4.0.0 proposal - getting to alpha In-Reply-To: References: Message-ID: On Sun, Nov 17, 2013 at 12:25 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > There's currently an issue with Alex happy when they're built with clang > cpp rather Than GCC cpp which some folks are trying to hammer out I think. > I think it's a problem in Alex 3.1.2 but not 3.1.0. Sorry, this isn't clear to me, even after reading the bug reports! Do this mean that alex, when itself is built with clang, no longer works correctly? If that is in the ball park, I don't think it is an issue: The Mac OS X version of Haskell Platform will be built via gcc, not clang. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon Nov 18 06:09:02 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 18 Nov 2013 01:09:02 -0500 Subject: 2013.4.0.0 proposal - getting to alpha In-Reply-To: References: Message-ID: good point, pardon any confusion. On Mon, Nov 18, 2013 at 12:49 AM, Mark Lentczner wrote: > On Sun, Nov 17, 2013 at 12:25 PM, Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> There's currently an issue with Alex happy when they're built with clang >> cpp rather Than GCC cpp which some folks are trying to hammer out I think. >> I think it's a problem in Alex 3.1.2 but not 3.1.0. > > > Sorry, this isn't clear to me, even after reading the bug reports! Do this > mean that alex, when itself is built with clang, no longer works correctly? > If that is in the ball park, I don't think it is an issue: The Mac OS X > version of Haskell Platform will be built via gcc, not clang. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.dijk.bas at gmail.com Mon Nov 18 07:52:03 2013 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Mon, 18 Nov 2013 08:52:03 +0100 Subject: Proposal: Add `instance Bits Bool` In-Reply-To: References: Message-ID: +1 On 10 Nov 2013 23:33, "Edward Kmett" wrote: > We went through all the pain of removing Num as a superclass of Bits to > support it, but we apparently never actually put the instance of Bits (and > FiniteBits) for Bool into base. > > I propose we do so. > > Discussion Period: 2 weeks > > -Edward > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.leather at gmail.com Mon Nov 18 08:04:47 2013 From: sean.leather at gmail.com (Sean Leather) Date: Mon, 18 Nov 2013 10:04:47 +0200 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: References: Message-ID: On Sun, Nov 17, 2013 at 10:20 PM, Mark Lentczner wrote: > Thoughts? I'm fine with any option regarding dlist. Just to update people on my planned changes for v0.6, here is the ChangeLog : * Maintenance and development taken over by Sean Leather * Migrate repository from http://code.haskell.org/~dons/code/dlist/ to https://github.com/spl/dlist * Add `Eq`, `Ord`, `Read`, `Show`, `Alternative`, `Foldable`, `Traversable` instances * Deprecate functions in favor of their type class equivalents: `concat`, `map`, `foldr` * Deprecate `DL`, `unDL` and add `apply` ([#4]( https://github.com/spl/dlist/issues/4)) * Stop supporting `base < 2` * Update tests to run `cabal test` using parallel QuickCheck (`pqc`) * Add scripts for running `hpc` * Update documentation Other than minor documentation updates, all of these changes are implemented. I have no further plans for v0.6. Regards, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon Nov 18 09:21:44 2013 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 18 Nov 2013 09:21:44 +0000 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: References: Message-ID: <1384766504.2488.10.camel@kirk> Hi, Am Montag, den 18.11.2013, 10:04 +0200 schrieb Sean Leather: > * Maintenance and development taken over by Sean Leather > * Migrate repository from http://code.haskell.org/~dons/code/dlist/ to > https://github.com/spl/dlist > * Add `Eq`, `Ord`, `Read`, `Show`, `Alternative`, `Foldable`, `Traversable` > instances Given that the point of dlist is to speed up code where lists are insufficient, would it make sense to only provide those instances that can be implemented without converting to and from lists? If there are instances that cannot be implemented idiomatically with dlists, maybe they should be left out, to signal the user that he will not get the benefits of DLists for these. In particular, it seems that the Show instance could be improved. Currently it says showsPrec p dl = showParen (p > 10) $ showString "fromList " . shows (toList dl) i.e. goes via a list. But this is constructing a ShowS (which is String -> String) value, i.e. another difference list. Shouldn?t it be possible to stay in the world of difference lists when implementing this? (Or maybe I?m overly worried, and I admit that I did not run benchmarks so far.) Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From ivan.miljenovic at gmail.com Mon Nov 18 10:06:13 2013 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Mon, 18 Nov 2013 21:06:13 +1100 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: References: Message-ID: On 18 November 2013 19:04, Sean Leather wrote: > On Sun, Nov 17, 2013 at 10:20 PM, Mark Lentczner wrote: >> >> Thoughts? > > > I'm fine with any option regarding dlist. > > Just to update people on my planned changes for v0.6, here is the ChangeLog: > > * Maintenance and development taken over by Sean Leather > * Migrate repository from http://code.haskell.org/~dons/code/dlist/ to > https://github.com/spl/dlist > * Add `Eq`, `Ord`, `Read`, `Show`, `Alternative`, `Foldable`, `Traversable` > instances > * Deprecate functions in favor of their type class equivalents: `concat`, > `map`, > `foldr` > * Deprecate `DL`, `unDL` and add `apply` The only possible issue I can think of with this from my own experience in dealing with my own code with abstract data types with no exposed constructors: it made some debugging issues difficult to diagnose because the equivalent of fromList and toList led to some subtle behaviours. As such, what about having an .Internals module that exposes these? (Admittedly in my case, the issue was more because of the behaviour of show and read, which isn't as big a deal with a datatype that doesn't change the ordering of list elements.) > ([#4](https://github.com/spl/dlist/issues/4)) > * Stop supporting `base < 2` > * Update tests to run `cabal test` using parallel QuickCheck (`pqc`) > * Add scripts for running `hpc` > * Update documentation > > Other than minor documentation updates, all of these changes are > implemented. I have no further plans for v0.6. > > Regards, > Sean > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From sean.leather at gmail.com Mon Nov 18 15:15:10 2013 From: sean.leather at gmail.com (Sean Leather) Date: Mon, 18 Nov 2013 17:15:10 +0200 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: <1384766504.2488.10.camel@kirk> References: <1384766504.2488.10.camel@kirk> Message-ID: Hi Joachim, I did not want to derail the conversation about the pros and cons of dlist, so I started a separate thread about it on the haskell-platform list [1], but perhaps I should have included the libraries list [2]. Since a few people have mentioned concerns about dlist/list conversion, I will respond below. On Mon, Nov 18, 2013 at 11:21 AM, Joachim Breitner wrote: > Am Montag, den 18.11.2013, 10:04 +0200 schrieb Sean Leather: > > * Maintenance and development taken over by Sean Leather > > * Migrate repository from http://code.haskell.org/~dons/code/dlist/ to > > https://github.com/spl/dlist > > * Add `Eq`, `Ord`, `Read`, `Show`, `Alternative`, `Foldable`, > `Traversable` > > instances > > Given that the point of dlist is to speed up code where lists are > insufficient, To be a bit more precise, it is not that lists are "insufficient," the problem is the `(++)` operator (a.k.a. append). To be even more precise, the problem is left-nested appends, e.g. the expression `(x ++ y) ++ z` may have a worse traversal time than `x ++ (y ++ z)`. Such an arrangement can (and probably will) result in multiple traversals of the left argument(s). would it make sense to only provide those instances that > can be implemented without converting to and from lists? > In my opinion, no. It makes sense to have as many reasonable instances as possible to make the library more attractive and usable. The fact that the instances convert to and from lists does not detract from their usefulness because the conversions are not necessarily inefficient (see next response). If there are instances that cannot be implemented idiomatically with > dlists, maybe they should be left out, to signal the user that he will > not get the benefits of DLists for these. > I think it is an unproven myth that conversion between lists and dlists is always inefficient. Consider the conversion functions: > fromList :: [a] -> DList a > fromList = DL . (++) > toList :: DList a -> [a] > toList = ($[]) . unDL Converting from a list is like prepending (++) to a list. This introduces a linear traversal of the argument (assuming a complete evaluation of the converted list). Converting to a list is like "finishing it off" with an empty list. The operation itself is trivial, but traversing the result would evaluate all the `(++)` from the previous `fromList`s. Fortunately, all of the `fromList`ed lists are left-arguments to `(++)`, so each will only be traversed once (which is the primary reason of dlists). Looking at the instances in the master branch, most of them use `toList`, which we have established is trivial. The only instances to use `fromList` are `Read` and `Traversable`. Each of these reuses the list instance and involves at least one list traversal, so the extra traversal implied by `fromList` means a constant factor increase in time. In particular, it seems that the Show instance could be improved. > Currently it says > showsPrec p dl = showParen (p > 10) $ > showString "fromList " . shows (toList dl) > i.e. goes via a list. But this is constructing a ShowS (which is String > -> String) value, i.e. another difference list. Shouldn?t it be possible > to stay in the world of difference lists when implementing this? > Perhaps you might expect this: > showsPrec' :: Int -> DList Char -> ShowS > showsPrec' p dl = showParen (p > 10) $ > showString "fromList " . unDL dl But that won't work, because we have a `Show a => DList a`, not a `DList Char`. The `Show` instance for lists is for `Show a => [a]`, not `[Char]`. See Bas' dstring library for `DList Char`. The underlying representation of dlists is `[a] -> [a]`, so what we might want is a function with the type `Show a => ([a] -> [a]) -> ShowS`. But we don't need or want to map `String` to `Show a => [a]` as one might think the higher-order function requires. What we do is finish off the function with `[]` (which is appended to the end of the resulting list). Then, we're left with something of type `Show a => [a]`, to which we can apply `showList`. Looking back at the instance, `toList` finishes the function and `shows` for `[a]` is equivalent to `showList` for `a`. (Or maybe I?m overly worried, and I admit that I did not run benchmarks > so far.) > I definitely think benchmarks [3] would help resolve these questions. And there might be cases where rewrite rules and fusion play a role. But until then, I remain unconvinced that the added instances are anything but helpful. Regards, Sean [1] http://projects.haskell.org/pipermail/haskell-platform/2013-November/002750.html [2] I assumed the discussion for a library being added (or not) to the Platform should happen on haskell-platform and not libraries. But perhaps libraries has more eyes and interest. The fact that many of these emails are being sent to both lists adds to my confusion about where discussion should take place. [3] https://github.com/spl/dlist/issues/3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.leather at gmail.com Mon Nov 18 15:37:26 2013 From: sean.leather at gmail.com (Sean Leather) Date: Mon, 18 Nov 2013 17:37:26 +0200 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: References: Message-ID: Hi Ivan, On Mon, Nov 18, 2013 at 12:06 PM, Ivan Lazar Miljenovic wrote: > On 18 November 2013 19:04, Sean Leather wrote: > > * Deprecate `DL`, `unDL` and add `apply` > > The only possible issue I can think of with this from my own > experience in dealing with my own code with abstract data types with > no exposed constructors: it made some debugging issues difficult to > diagnose because the equivalent of fromList and toList led to some > subtle behaviours. As such, what about having an .Internals module > that exposes these? > I think the type DList should be abstract. Sometimes, there are occasions in which it is useful to have access to constructors. Examples include debugging (yours), implementing functions not included in the library (e.g. this comes up sometimes with Data.Map/Data.Set), and optimization. In the case of DList, the underlying type is so simple that exposing it does not add enough value to warrant a second module. My guess is that the most likely reason for using the constructor is to bypass `fromList`, but this is much more likely to lead to unexpected values [1] than anything useful (or optimized). Regards, Sean [1] https://github.com/spl/dlist/issues/4 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at nh2.me Mon Nov 18 16:21:27 2013 From: mail at nh2.me (=?ISO-8859-1?Q?Niklas_Hamb=FCchen?=) Date: Mon, 18 Nov 2013 16:21:27 +0000 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: References: Message-ID: <528A3E87.7000605@nh2.me> On 18/11/13 15:37, Sean Leather wrote: > Examples > include debugging (yours), implementing functions not included in the > library (e.g. this comes up sometimes with Data.Map/Data.Set), and > optimization. ... > In the case of DList, the underlying type is so simple > that exposing it does not add enough value to warrant a second module. These two points you give seem very contradicting. >From my experience, whatever it is, in the end somebody wants to give an instance to it. I would therefore vote to expose internals of *all* data types exposed. Not doing so is assuming the ability to foretell everything a user will ever do with it, which is never true. From simons at cryp.to Mon Nov 18 16:40:57 2013 From: simons at cryp.to (Peter Simons) Date: Mon, 18 Nov 2013 17:40:57 +0100 Subject: aeson and dlist in HP 2013.4.0.0 References: <528A3E87.7000605@nh2.me> Message-ID: <87zjp13bom.fsf@write-only.cryp.to> Niklas Hamb?chen writes: > I would therefore vote to expose internals of *all* data types exposed. > Not doing so is assuming the ability to foretell everything a user will > ever do with it, which is never true. I agree. I had plenty of trouble because libraries hid types and/or functions that I needed access to, but I never had any trouble because a library exposed a type that I didn't need access to. Take care, Peter From Christian.Maeder at dfki.de Mon Nov 18 17:07:09 2013 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon, 18 Nov 2013 18:07:09 +0100 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: <528A3E87.7000605@nh2.me> References: <528A3E87.7000605@nh2.me> Message-ID: <528A493D.7090403@dfki.de> Am 18.11.2013 17:21, schrieb Niklas Hamb?chen: > On 18/11/13 15:37, Sean Leather wrote: >> Examples >> include debugging (yours), implementing functions not included in the >> library (e.g. this comes up sometimes with Data.Map/Data.Set), and >> optimization. > > ... > >> In the case of DList, the underlying type is so simple >> that exposing it does not add enough value to warrant a second module. > > These two points you give seem very contradicting. > >>From my experience, whatever it is, in the end somebody wants to give an > instance to it. > > I would therefore vote to expose internals of *all* data types exposed. You do not believe in abstract data types, do you? With the constructor exposed you can spoil invariants, i.e. for DList: wrongEmptyList = DL $ const [] toList $ append wrongEmptyList $ fromList [1] yields "[]". Cheers Christian > Not doing so is assuming the ability to foretell everything a user will > ever do with it, which is never true. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > From greg at gregorycollins.net Mon Nov 18 17:14:17 2013 From: greg at gregorycollins.net (Gregory Collins) Date: Mon, 18 Nov 2013 18:14:17 +0100 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: <87zjp13bom.fsf@write-only.cryp.to> References: <528A3E87.7000605@nh2.me> <87zjp13bom.fsf@write-only.cryp.to> Message-ID: On Mon, Nov 18, 2013 at 5:40 PM, Peter Simons wrote: > ...but I never had any trouble because > a library exposed a type that I didn't need access to. > I've definitely had the experience of pattern matching on somebody's constructor and then having my code break when a new record field was added. The convention I use, and which I have seen others use, is that datatypes are exported abstractly in "public" APIs but are also (optionally) exported from an ".Internal" module. The "contract" you give to API users about what kinds of changes should be breaking can then be a little stronger in the public API. Consumers of modules marked "internal" deserve what they get :) Other concrete examples where this has helped me as a library author in the past: In the snap-core web programming package, I have redefined the "Snap" monad half a dozen times but consumers of the public library API have to my recollection never been affected by these changes. This would not be possible without the datatype abstraction. As others have posted, keeping datatypes abstract also lets you maintain invariants that unfettered access to the datatype constructors might allow you to violate. For dozens of reasons it's a software engineering "best practice". G -- Gregory Collins -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at nh2.me Mon Nov 18 18:00:32 2013 From: mail at nh2.me (=?ISO-8859-1?Q?Niklas_Hamb=FCchen?=) Date: Mon, 18 Nov 2013 18:00:32 +0000 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: <528A493D.7090403@dfki.de> References: <528A3E87.7000605@nh2.me> <528A493D.7090403@dfki.de> Message-ID: <528A55C0.7010101@nh2.me> On 18/11/13 17:07, Christian Maeder wrote: > You do not believe in abstract data types, do you? > > With the constructor exposed you can spoil invariants I understand it that everybody in this thread is talking about exporting it in an .Internal module as is common practice. Like Gregory said: Consumers of modules marked "internal" deserve what they get. From hesselink at gmail.com Mon Nov 18 18:44:56 2013 From: hesselink at gmail.com (Erik Hesselink) Date: Mon, 18 Nov 2013 19:44:56 +0100 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: <87zjp13bom.fsf@write-only.cryp.to> References: <528A3E87.7000605@nh2.me> <87zjp13bom.fsf@write-only.cryp.to> Message-ID: On Monday, November 18, 2013, Peter Simons wrote: > Niklas Hamb?chen writes: > > > I would therefore vote to expose internals of *all* data types exposed. > > Not doing so is assuming the ability to foretell everything a user will > > ever do with it, which is never true. > > I agree. I had plenty of trouble because libraries hid types and/or > functions that I needed access to, but I never had any trouble because > a library exposed a type that I didn't need access to. > +1 Erik -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.leather at gmail.com Mon Nov 18 19:54:36 2013 From: sean.leather at gmail.com (Sean Leather) Date: Mon, 18 Nov 2013 21:54:36 +0200 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: <528A3E87.7000605@nh2.me> References: <528A3E87.7000605@nh2.me> Message-ID: On Mon, Nov 18, 2013 at 6:21 PM, Niklas Hamb?chen wrote: > On 18/11/13 15:37, Sean Leather wrote: > > Examples > > include debugging (yours), implementing functions not included in the > > library (e.g. this comes up sometimes with Data.Map/Data.Set), and > > optimization. > > ... > > > In the case of DList, the underlying type is so simple > > that exposing it does not add enough value to warrant a second module. > > These two points you give seem very contradicting. > The points are contradictory, but my message was not. I accept that there are reasons to expose constructors, but in this case, I think (1) the reason to hide the DList constructor is strong and (2) the reasons to expose the constructor are weak. Of course, this is somewhat subjective, but I have given evidence why the constructor should be hidden, and I have not seen any non-speculative evidence why it should be exposed. >From my experience, whatever it is, in the end somebody wants to give an > instance to it. > In case you haven't seen the code [1], none of the included instances need the constructor. And, since dlists are easily (and, as I argued earlier, probably efficiently) converted to/from lists, those supposed instances that somebody wants to give can be implemented in the same way. Access to the constructor does not help there. I would therefore vote to expose internals of *all* data types exposed. > Not doing so is assuming the ability to foretell everything a user will > ever do with it, which is never true. > Actually, I do want to prevent one thing that a user will do with the library: construct a `DList` from an arbitrary `[a] -> [a]` function. That's the point, and the library user loses little and gains a strong assurance of safety. I think I have said enough for this thread. If anyone can come up with a concrete (and safe) example of using the DList constructor outside the library, I would consider that as evidence for exposing it. It's exposed in v0.5 and will be deprecated in v0.6, so there's plenty of time to try. It's always possible to change the code later, too. As I said before [2], I think dlist is perfectly suitable for the Platform, but since it has so far been considered (1) only as a minor dependency to aeson (the formally proposed addition) and (2) somewhat controversial, the aeson proposal might be better simplified to aeson-without-dlist. Regardless of the final choice, however, I'm happy to develop and maintain dlist. Regards, Sean [1] https://github.com/spl/dlist/blob/master/Data/DList.hs [2] http://projects.haskell.org/pipermail/haskell-platform/2013-November/002750.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwlato at gmail.com Tue Nov 19 01:32:52 2013 From: jwlato at gmail.com (John Lato) Date: Mon, 18 Nov 2013 17:32:52 -0800 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: References: <1384766504.2488.10.camel@kirk> Message-ID: Hi Sean, Since I've raised this issue before as well, I decided to write some tests. At this time, I've written/run criterion tests, and I have some hand-wavey theoretical arguments. The theoretical stuff came first (presented below) and isn't influenced by the test results, which I haven't attempted to analyze beyond the most superficial level. If anyone else really cares strongly, please feel free to develop this further. https://github.com/JohnLato/dlist-test/ http://htmlpreview.github.io/?https://github.com/JohnLato/dlist-test/blob/master/testout.html I think more research is warranted, since there are a few anomalies I can't currently explain. On Mon, Nov 18, 2013 at 7:15 AM, Sean Leather wrote: > Hi Joachim, > > On Mon, Nov 18, 2013 at 11:21 AM, Joachim Breitner wrote: > > Am Montag, den 18.11.2013, 10:04 +0200 schrieb Sean Leather: >> > * Maintenance and development taken over by Sean Leather >> > * Migrate repository from http://code.haskell.org/~dons/code/dlist/ to >> > https://github.com/spl/dlist >> > * Add `Eq`, `Ord`, `Read`, `Show`, `Alternative`, `Foldable`, >> `Traversable` >> > instances >> >> Given that the point of dlist is to speed up code where lists are >> insufficient, > > > To be a bit more precise, it is not that lists are "insufficient," the > problem is the `(++)` operator (a.k.a. append). To be even more precise, > the problem is left-nested appends, e.g. the expression `(x ++ y) ++ z` may > have a worse traversal time than `x ++ (y ++ z)`. Such an arrangement can > (and probably will) result in multiple traversals of the left argument(s). > > would it make sense to only provide those instances that >> can be implemented without converting to and from lists? >> > > In my opinion, no. It makes sense to have as many reasonable instances as > possible to make the library more attractive and usable. The fact that the > instances convert to and from lists does not detract from their usefulness > because the conversions are not necessarily inefficient (see next response). > > If there are instances that cannot be implemented idiomatically with >> dlists, maybe they should be left out, to signal the user that he will >> not get the benefits of DLists for these. >> > > I think it is an unproven myth that conversion between lists and dlists is > always inefficient. Consider the conversion functions: > > > fromList :: [a] -> DList a > > fromList = DL . (++) > > > toList :: DList a -> [a] > > toList = ($[]) . unDL > > Converting from a list is like prepending (++) to a list. This introduces > a linear traversal of the argument (assuming a complete evaluation of the > converted list). > > Converting to a list is like "finishing it off" with an empty list. The > operation itself is trivial, but traversing the result would evaluate all > the `(++)` from the previous `fromList`s. Fortunately, all of the > `fromList`ed lists are left-arguments to `(++)`, so each will only be > traversed once (which is the primary reason of dlists). > This overlooks the cost of evaluating the DList function itself, which can be significant. DLists are usually formed by snoc'ing/appending k elements/chunks, which means that the total DList is a composition of k separate functions. This structure must be traversed in order to evaluate the resulting list, which makes 'toList' have complexity O(k). If the DList was formed by repeated 'snoc' calls (maybe a common case, maybe not), k==n. calling 'toList' isn't so bad on its own, as typically it only happens once. My concern stems from situations such as using DList as a key in a map, for which many comparisons will be performed and toList will be called multiple times on some elements. Even considering this, I'm not particularly opposed to these instances, but I think users should be aware that they can lead to repeated non-trivial computations. John L. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.leather at gmail.com Tue Nov 19 09:37:56 2013 From: sean.leather at gmail.com (Sean Leather) Date: Tue, 19 Nov 2013 11:37:56 +0200 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: References: <1384766504.2488.10.camel@kirk> Message-ID: Hi John, On Tue, Nov 19, 2013 at 3:32 AM, John Lato wrote: > Since I've raised this issue before as well, I decided to write some tests. > > At this time, I've written/run criterion tests, and I have some hand-wavey > theoretical arguments. The theoretical stuff came first (presented below) > and isn't influenced by the test results, which I haven't attempted to > analyze beyond the most superficial level. If anyone else really cares > strongly, please feel free to develop this further. > > https://github.com/JohnLato/dlist-test/ > > http://htmlpreview.github.io/?https://github.com/JohnLato/dlist-test/blob/master/testout.html > Great! Thanks! I think more research is warranted, since there are a few anomalies I can't > currently explain. > Definitely. On Mon, Nov 18, 2013 at 7:15 AM, Sean Leather wrote: > >> Converting from a list is like prepending (++) to a list. This introduces >> a linear traversal of the argument (assuming a complete evaluation of the >> converted list). >> >> Converting to a list is like "finishing it off" with an empty list. The >> operation itself is trivial, but traversing the result would evaluate all >> the `(++)` from the previous `fromList`s. Fortunately, all of the >> `fromList`ed lists are left-arguments to `(++)`, so each will only be >> traversed once (which is the primary reason of dlists). >> > > This overlooks the cost of evaluating the DList function itself, which can > be significant. DLists are usually formed by snoc'ing/appending k > elements/chunks, which means that the total DList is a composition of k > separate functions. This structure must be traversed in order to evaluate > the resulting list, which makes 'toList' have complexity O(k). If the > DList was formed by repeated 'snoc' calls (maybe a common case, maybe not), > k==n. > True, and nicely put. calling 'toList' isn't so bad on its own, as typically it only happens > once. My concern stems from situations such as using DList as a key in a > map, for which many comparisons will be performed and toList will be called > multiple times on some elements. > Indeed. I would hope there would be sharing in those cases, but I'm not sure right now. Even considering this, I'm not particularly opposed to these instances, but > I think users should be aware that they can lead to repeated non-trivial > computations. > Agreed. Regards, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkn.akio at gmail.com Wed Nov 20 07:40:53 2013 From: tkn.akio at gmail.com (Akio Takano) Date: Wed, 20 Nov 2013 16:40:53 +0900 Subject: Proposal: add fusion RULES for Data.Map.mapMaybe Message-ID: Hi, Currently mapMaybe does not fuse at all. The attached patch implements necessary rules for fold/build fusion in both sides (the result and the second argument) to happen. When fusion does not happen, the function should behave exactly the same as before. I ran some benchmarks, testing cases where fusion does and does not happen: http://htmlpreview.github.io/?https://github.com/takano-akio/mapmaybe-benchmarks/blob/master/out.html The benchmark code is: https://github.com/takano-akio/mapmaybe-benchmarks/blob/master/main.hs Discussion period: 2 weeks. Thank you, Takano Akio -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-fusion-RULES-for-mapMaybe.patch Type: text/x-patch Size: 922 bytes Desc: not available URL: From tkn.akio at gmail.com Wed Nov 20 07:46:21 2013 From: tkn.akio at gmail.com (Akio Takano) Date: Wed, 20 Nov 2013 16:46:21 +0900 Subject: Proposal: add fusion RULES for Data.Maybe.mapMaybe Message-ID: Apologies, the subject of my previous email was wrong. It is about Data.Maybe.mapMaybe, not Data.Map.mapMaybe. On Wed, Nov 20, 2013 at 4:40 PM, Akio Takano wrote: > Hi, > > Currently mapMaybe does not fuse at all. The attached patch implements > necessary rules for fold/build fusion in both sides (the result and the > second argument) to happen. When fusion does not happen, the function > should behave exactly the same as before. > > I ran some benchmarks, testing cases where fusion does and does not happen: > > > http://htmlpreview.github.io/?https://github.com/takano-akio/mapmaybe-benchmarks/blob/master/out.html > > The benchmark code is: > > https://github.com/takano-akio/mapmaybe-benchmarks/blob/master/main.hs > > Discussion period: 2 weeks. > > Thank you, > Takano Akio > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan at rochel.info Wed Nov 20 11:00:45 2013 From: jan at rochel.info (Jan Rochel) Date: Wed, 20 Nov 2013 12:00:45 +0100 Subject: Maintaintership of HaLeX Message-ID: <528C965D.3000903@rochel.info> Hello. The current version (1.2) of HaLeX does not build on my machine (ghc-7.6.3). The fix is very simple*, but the package maintainer has not reacted on any of my emails during the last couple of months. I'd be willing to take over maintainership, if people agree that this is the best course of action. Otherwise I'd upload an additional fixed variant of the package. Greetings, Jan * add assumption (Eq st) on lines 80 and 104 of file HaLeX_lib/Language/HaLex/Fa2RegExp.hs From rrnewton at gmail.com Wed Nov 20 15:06:08 2013 From: rrnewton at gmail.com (Ryan Newton) Date: Wed, 20 Nov 2013 10:06:08 -0500 Subject: Best way to get to CAS/fetch-and-add on unboxed vectors? Message-ID: Since GHC 7.8 will now absorb the functionality that was previously only in the atomic-primops package, it would be great to start exposing this for the data structures people actually want to use: i.e. unboxed vectors rather than raw MutableByteArrays . I've been reading through the code of vector, thinking that I would release some kind of "vector-atomics" package. Alas, I don't see how that is possible. There's no way to get at the MutableByteArray associated with an unboxed vector. (1) I think the minimum that would be necessary would be to modify "Data/Vector/Unboxed/Base.hs", where the instances for the type family actually exist, to provide an additional instance for each "MVector s Foo" that records the fact that the vector has and can expose a MutableByteArray. (2) Alternatively, an "exposeMutableByteArray" function could be added to the existing Unbox class. But this would affect other third party Unbox instances out there in the world... Is there any interest insupporting Unbox instances that are NOT implemented as a MutableByteArray? (3) The most invasive (but best for the user) change would be to extend the basic MVector interface to include notions of concurrency-related operations right inside the vector package (CAS, etc). But they should still probably go in a separate class (not class MVector), just because they will be specific to Unboxed and Storable vectors rather than boxed ones.... -Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmaessen at alum.mit.edu Wed Nov 20 15:21:07 2013 From: jmaessen at alum.mit.edu (Jan-Willem Maessen) Date: Wed, 20 Nov 2013 10:21:07 -0500 Subject: Best way to get to CAS/fetch-and-add on unboxed vectors? In-Reply-To: References: Message-ID: On Wed, Nov 20, 2013 at 10:06 AM, Ryan Newton wrote: > (3) The most invasive (but best for the user) change would be to extend > the basic MVector interface to include notions of concurrency-related > operations right inside the vector package (CAS, etc). But they should > still probably go in a separate class (not class MVector), just because > they will be specific to Unboxed and Storable vectors rather than boxed > ones.... > Any reason we shouldn't be able to CAS on boxed vectors? Every architecture supports a pointer-sized CAS. What "equality" means for CAS, of course, has to be rather carefully defined, but that's equally true for the unboxed types. -Jan > > -Ryan > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duncan at well-typed.com Wed Nov 20 15:37:56 2013 From: duncan at well-typed.com (Duncan Coutts) Date: Wed, 20 Nov 2013 15:37:56 +0000 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: References: Message-ID: <1384961876.7607.186.camel@dunky.localdomain> On Sun, 2013-11-17 at 12:20 -0800, Mark Lentczner wrote: > *Options for aeson:* > > 1. skip it in this release > 2. include *aeson* 0.6.2.1 - requiring both *dlist* and *blaze-builder* > 3. include *aeson* 0.6.2.x, a version with the patch that uses > *bytestring*'s builder, and so require only *dlist* > 4. include *aeson* 0.7.0.0 - requiring *dlist* and possibly *scientific* I would strongly argue against including blaze-builder in the platform. The whole point of the work Simon Meier (and Johan and myself) have done over the last year or so with adding Builder into the bytestring package was so that we could get a good implementation with a good API into the platform (and in the appropriate place). It would be silly at this point to confuse matters for users. So I don't mind if there is an aeson-0.6.2.x or a 0.7.x release, so long as it's using the bytestring builder and not blaze-builder. And of course note that the current 2013.2 HP already includes bytestring-0.10 which has the new builder API. -- Duncan Coutts, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From duncan at well-typed.com Wed Nov 20 15:45:54 2013 From: duncan at well-typed.com (Duncan Coutts) Date: Wed, 20 Nov 2013 15:45:54 +0000 Subject: 2013.4.0.0 proposal In-Reply-To: References: Message-ID: <1384962354.7607.188.camel@dunky.localdomain> On Sun, 2013-11-10 at 14:14 -0800, Mark Lentczner wrote: > I spoke too soon: > *cgi* 3001.1.8.4 induces *MonadCatchIO-mtl* & *extensible-exceptions* - > this is more problematic: > > - *extensible-exceptions* hasn't been needed since GHC 7, and just > reexports stuff into a different place. I don't think that should be in the > platform. > - *MonadCatchIO-mtl* is one of several approaches to re-mapping > extensible exceptions into *mtl*. While none is settled practice yet, > this one is probably a dead end as it uses the older block/unblock idiom > rather than the now preferred mask idiom. > > I'm planning holding *cgi* back to 3001.1.7.5 to avoid these two packages. That seems wise. Query it with the maintainer (reminding of the all deps in HP rule) and hopefully we can have it back next time. -- Duncan Coutts, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From rrnewton at gmail.com Wed Nov 20 15:57:13 2013 From: rrnewton at gmail.com (Ryan Newton) Date: Wed, 20 Nov 2013 10:57:13 -0500 Subject: Best way to get to CAS/fetch-and-add on unboxed vectors? In-Reply-To: References: Message-ID: We do expose CAS for boxed data, and we depend on that for various concurrent data structures (e.g. Michael-scott queues). But it's a messy business: You have to fight hard against the GHC optimizer to prevent it from performing optimizations (e.g. unbox and rebox an Int) that completely destroy pointer equality (in all runs of the program). The way that we've codified our solution to this is to use abstract "Ticket"s (based on the Any kind) that GHC is not supposed to be able to see through. These are used to abstractly represent old reads when you come back to do a new CAS operation: http://hackage.haskell.org/package/atomic-primops-0.4/docs/Data-Atomics.html#g:2 Even then, there was a bunch of careful NOINLINE's and other business necessary to achieve something workable, and it's highly GHC specific. If we were to expose CAS on boxed "Data.Vector", I think it would only make sense as the ticketed interface above (raw CAS is useless, and will just condemn others to the same problems we had). As a result of all this the CAS for Data.Vector would have a different signature (unless we wanted to force Storable/Unbox to use Tickets), and thus couldn't go in the "MVector" type class along with all the other basic operations that are uniform across representations. That said, it's easy to provide CAS from a separate "vector-atomics" package, because Data.Vector exposes the MVector constructor that lets you get at the underlying MutableArray. So we certainly can provide the functionality somewhere, somehow. -Ryan On Wed, Nov 20, 2013 at 10:21 AM, Jan-Willem Maessen wrote: > On Wed, Nov 20, 2013 at 10:06 AM, Ryan Newton wrote: > >> (3) The most invasive (but best for the user) change would be to extend >> the basic MVector interface to include notions of concurrency-related >> operations right inside the vector package (CAS, etc). But they should >> still probably go in a separate class (not class MVector), just because >> they will be specific to Unboxed and Storable vectors rather than boxed >> ones.... >> > > Any reason we shouldn't be able to CAS on boxed vectors? Every > architecture supports a pointer-sized CAS. What "equality" means for CAS, > of course, has to be rather carefully defined, but that's equally true for > the unboxed types. > > -Jan > > >> >> -Ryan >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.skladnoy at gmail.com Wed Nov 20 16:53:59 2013 From: alexey.skladnoy at gmail.com (Aleksey Khudyakov) Date: Wed, 20 Nov 2013 17:53:59 +0100 Subject: Best way to get to CAS/fetch-and-add on unboxed vectors? In-Reply-To: References: Message-ID: On 20 November 2013 16:06, Ryan Newton wrote: > Since GHC 7.8 will now absorb the functionality that was previously only in > the atomic-primops package, it would be great to start exposing this for the > data structures people actually want to use: i.e. unboxed vectors rather > than raw MutableByteArrays. > > I've been reading through the code of vector, thinking that I would release > some kind of "vector-atomics" package. Alas, I don't see how that is > possible. There's no way to get at the MutableByteArray associated with an > unboxed vector. > > (1) I think the minimum that would be necessary would be to modify > "Data/Vector/Unboxed/Base.hs", where the instances for the type family > actually exist, to provide an additional instance for each "MVector s Foo" > that records the fact that the vector has and can expose a MutableByteArray. > > (2) Alternatively, an "exposeMutableByteArray" function could be added to > the existing Unbox class. But this would affect other third party Unbox > instances out there in the world... Is there any interest insupporting > Unbox instances that are NOT implemented as a MutableByteArray? > AFAIR unboxed vector of tuples are implemented as tuple of vectors so there're many underlying vectors and array of () implemented as simple Int. Whole point of unboxed vector is to give flexibility in representation of arrays From bos at serpentine.com Wed Nov 20 17:20:41 2013 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed, 20 Nov 2013 09:20:41 -0800 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: <1384961876.7607.186.camel@dunky.localdomain> References: <1384961876.7607.186.camel@dunky.localdomain> Message-ID: On Wed, Nov 20, 2013 at 7:37 AM, Duncan Coutts wrote: > I would strongly argue against including blaze-builder in the platform. > Right, I don't think anyone wants that. It's no longer a dependency of the current development version of aeson, if the platform bytestring is new enough. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Wed Nov 20 21:38:22 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 20 Nov 2013 16:38:22 -0500 Subject: Best way to get to CAS/fetch-and-add on unboxed vectors? In-Reply-To: References: Message-ID: Ryan, would you please file a ticket on GHC trac explaining WHY ghc makes it difficult to support CAS for boxed vectors? And you would like to be able to do vs what you have had to do? Understanding why its currently difficult to write new primitives for lockfree concurrency in user land seems like something worth digging deeper into! (and perhaps trying to fix!) as much as CAS on Storable / Unboxed would be cool, It seems like it'd only work on instances that are actually 4,8,16 byte locations, right? I though Vector instances had their constructors exported so that you can get at the underlying Primitive vectors, and and Primitive vectors have a bytearray underneath! I don't understand why Vector/MVector needs to be changed here to support that info. For the Atomic operations, it seems like you just really want to only support the operations on vector types directly expressable with Primitive vectors. Perhaps i'm not understanding though. On Wed, Nov 20, 2013 at 10:57 AM, Ryan Newton wrote: > We do expose CAS for boxed data, and we depend on that for various > concurrent data structures (e.g. Michael-scott queues). > > But it's a messy business: > > You have to fight hard against the GHC optimizer to prevent > it from performing optimizations (e.g. unbox and rebox an Int) that > completely destroy pointer equality (in all runs of the program). The way > that we've codified our solution to this is to use abstract "Ticket"s > (based on the Any kind) that GHC is not supposed to be able to see through. > These are used to abstractly represent old reads when you come back to do > a new CAS operation: > > > http://hackage.haskell.org/package/atomic-primops-0.4/docs/Data-Atomics.html#g:2 > > Even then, there was a bunch of careful NOINLINE's and other business > necessary to achieve something workable, and it's highly GHC specific. If > we were to expose CAS on boxed "Data.Vector", I think it would only make > sense as the ticketed interface above (raw CAS is useless, and will just > condemn others to the same problems we had). > > > As a result of all this the CAS for Data.Vector would have a different > signature (unless we wanted to force Storable/Unbox to use Tickets), and > thus couldn't go in the "MVector" type class along with all the other basic > operations that are uniform across representations. > > That said, it's easy to provide CAS from a separate "vector-atomics" > package, because Data.Vector exposes the MVector constructor that lets you > get at the underlying MutableArray. So we certainly can provide the > functionality somewhere, somehow. > > -Ryan > > > > On Wed, Nov 20, 2013 at 10:21 AM, Jan-Willem Maessen < > jmaessen at alum.mit.edu> wrote: > >> On Wed, Nov 20, 2013 at 10:06 AM, Ryan Newton wrote: >> >>> (3) The most invasive (but best for the user) change would be to extend >>> the basic MVector interface to include notions of concurrency-related >>> operations right inside the vector package (CAS, etc). But they should >>> still probably go in a separate class (not class MVector), just because >>> they will be specific to Unboxed and Storable vectors rather than boxed >>> ones.... >>> >> >> Any reason we shouldn't be able to CAS on boxed vectors? Every >> architecture supports a pointer-sized CAS. What "equality" means for CAS, >> of course, has to be rather carefully defined, but that's equally true for >> the unboxed types. >> >> -Jan >> >> >>> >>> -Ryan >>> >>> >>> _______________________________________________ >>> 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 ashley at semantic.org Wed Nov 20 23:03:46 2013 From: ashley at semantic.org (Ashley Yakeley) Date: Wed, 20 Nov 2013 15:03:46 -0800 Subject: System.Posix.IO.ByteString fdRead and fdWrite. Message-ID: In unix-2.7.0.0, fdRead and fdWrite in System.Posix.IO.ByteString use String instead of ByteString. This is wrong, isn't it? The point of the .ByteString modules is to do IO in ByteString. -- Ashley From allbery.b at gmail.com Wed Nov 20 23:18:09 2013 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 20 Nov 2013 18:18:09 -0500 Subject: System.Posix.IO.ByteString fdRead and fdWrite. In-Reply-To: References: Message-ID: On Wed, Nov 20, 2013 at 6:03 PM, Ashley Yakeley wrote: > In unix-2.7.0.0, fdRead and fdWrite in System.Posix.IO.ByteString use > String instead of ByteString. This is wrong, isn't it? The point of the > .ByteString modules is to do IO in ByteString. > No. ByteString provides its own routines for that. The point of System.Posix.IO.ByteString is to provide a ByteString (which is to say, a correct POSIX) interface to *filesystem paths*. Using String for these is entirely incorrect, because POSIX pathnames are literally byte strings --- there is no encoding, just raw bytes with only '/' and '\NUL' being special. There are *lots* of programs that behave weirdly or crash because they assume the filesystem uses normalized UTF8, but absolutely nothing forces pathnames to be UTF8 much less normalized UTF8. (Gtk+ file dialogs tend to crash with non-UTF8-encoded filenames. They do even weirder things when filenames are UTF8 but not normalized. OS X native file dialogs have similar problems.) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Thu Nov 21 08:18:10 2013 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Thu, 21 Nov 2013 09:18:10 +0100 Subject: System.Posix.IO.ByteString fdRead and fdWrite. In-Reply-To: (Ashley Yakeley's message of "Wed, 20 Nov 2013 15:03:46 -0800") References: Message-ID: <87a9gyrwvx.fsf@gnu.org> On 2013-11-21 at 00:03:46 +0100, Ashley Yakeley wrote: > In unix-2.7.0.0, fdRead and fdWrite in System.Posix.IO.ByteString use > String instead of ByteString. This is wrong, isn't it? The point of > the .ByteString modules is to do IO in ByteString. Fwiw, here's the commit introducing the ByteString API and stating its intention: http://git.haskell.org/packages/unix.git/commitdiff/34c7bf896f19b182cf6fa104e057f1df9df1254a However, I'm not totally sure from that, whether the type-sigs fdRead :: Fd -> ByteCount -- ^How many bytes to read -> IO (String, ByteCount) -- ^ The bytes read, how many bytes were read. fdWrite :: Fd -> String -> IO ByteCount were really intended to be that way. Simon, maybe you can provide some insight here? Cheers, hvr From marlowsd at gmail.com Thu Nov 21 10:55:36 2013 From: marlowsd at gmail.com (Simon Marlow) Date: Thu, 21 Nov 2013 10:55:36 +0000 Subject: System.Posix.IO.ByteString fdRead and fdWrite. In-Reply-To: <87a9gyrwvx.fsf@gnu.org> References: <87a9gyrwvx.fsf@gnu.org> Message-ID: <528DE6A8.80103@gmail.com> On 21/11/13 08:18, Herbert Valerio Riedel wrote: > On 2013-11-21 at 00:03:46 +0100, Ashley Yakeley wrote: >> In unix-2.7.0.0, fdRead and fdWrite in System.Posix.IO.ByteString use >> String instead of ByteString. This is wrong, isn't it? The point of >> the .ByteString modules is to do IO in ByteString. > > Fwiw, here's the commit introducing the ByteString API and stating its intention: > > http://git.haskell.org/packages/unix.git/commitdiff/34c7bf896f19b182cf6fa104e057f1df9df1254a > > However, I'm not totally sure from that, whether the type-sigs > > > fdRead :: Fd > -> ByteCount -- ^How many bytes to read > -> IO (String, ByteCount) -- ^ The bytes read, how many bytes were read. > > fdWrite :: Fd -> String -> IO ByteCount > > > were really intended to be that way. > > Simon, maybe you can provide some insight here? Brandon's reply is correct, the ByteString variant of the POSIX API is intended to change the representation of file paths only. These two functions are totally useless and we need better versions anyway. Cheers, Simon From rrnewton at gmail.com Thu Nov 21 15:25:17 2013 From: rrnewton at gmail.com (Ryan Newton) Date: Thu, 21 Nov 2013 10:25:17 -0500 Subject: Best way to get to CAS/fetch-and-add on unboxed vectors? In-Reply-To: References: Message-ID: [@Aleksey] Very good point! I'd missed that vector does the SOA->AOS business too. (I thought that was just Repa & Accelerate.) In any case, an unboxed vector of tuples can't *actually* support atomic CAS anyway, so not supporting it is inevitable. It does mean that exposeMutableByteArray can't be a method of the Unbox class. It would need to be another class capturing the subset of vector types that are "Atomic" (support concurrent/atomic memory ops). -------------- next part -------------- An HTML attachment was scrubbed... URL: From rrnewton at gmail.com Thu Nov 21 15:30:07 2013 From: rrnewton at gmail.com (Ryan Newton) Date: Thu, 21 Nov 2013 10:30:07 -0500 Subject: Who needs and wants parallelism-friendly core libs? Message-ID: [Popping up to the big-picture question for a moment, from the previous thread on Vector CAS.] Given that a lot of people are really advertising Haskell on the parallel/concurrent front, it seems like we *should* be committed as a community to making our basic libraries support parallel/concurrent use cases effectively. This will necessarily mean touching some core libraries (container, vector...). The two things that have come up for me recently are (1) CAS/RMW on [unboxed] Vectors and a general notion of balanced-splitting for tree-based structures (Map,Set). But I'm sure there are others! Is any one else invested in getting this kind of thing moving? It would be great to have a partner. I can commit a small amount of cycles, but I don't have lots of bandwidth for non-research infrastructure work presently. Edward, is any of this useful to you? In many of these cases it seems like the main problem is not a technical one, but the social one of consensus building (and fighting excessive "stop energy" if it appears). Edward, as chair of the core libraries committee, maybe you could help with this? Cheers, -Ryan On Thu, Nov 21, 2013 at 10:25 AM, Ryan Newton wrote: > [@Aleksey] Very good point! I'd missed that vector does the SOA->AOS > business too. (I thought that was just Repa & Accelerate.) > > In any case, an unboxed vector of tuples can't *actually* support atomic > CAS anyway, so not supporting it is inevitable. > It does mean that exposeMutableByteArray can't be a method of the Unbox > class. It would need to be another class capturing the subset of vector > types that are "Atomic" (support concurrent/atomic memory ops). > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.skladnoy at gmail.com Thu Nov 21 15:52:06 2013 From: alexey.skladnoy at gmail.com (Aleksey Khudyakov) Date: Thu, 21 Nov 2013 16:52:06 +0100 Subject: Best way to get to CAS/fetch-and-add on unboxed vectors? In-Reply-To: References: Message-ID: On 21 November 2013 16:25, Ryan Newton wrote: > [@Aleksey] Very good point! I'd missed that vector does the SOA->AOS > business too. (I thought that was just Repa & Accelerate.) > > In any case, an unboxed vector of tuples can't actually support atomic CAS > anyway, so not supporting it is inevitable. > It does mean that exposeMutableByteArray can't be a method of the Unbox > class. It would need to be another class capturing the subset of vector > types that are "Atomic" (support concurrent/atomic memory ops). > > Data.Vector.Primitive? Uboxed vectors for doubles/ints/etc are just newtype wrapper over primitive vectors AFAIR. So we probably only need ability to coerce unboxed vector to primitive ones.. From ekmett at gmail.com Thu Nov 21 16:11:37 2013 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 21 Nov 2013 11:11:37 -0500 Subject: Who needs and wants parallelism-friendly core libs? In-Reply-To: References: Message-ID: I'd like to hash this out a bit further. As this issue affects vector primarily, it is outside of the scope of the core library committee per se, and is largely up to Roman as the maintainer of vector. That said if I put on my personal and not my 'committee' hat: I would use these operations, personally, were they available to me. The question is how to best expose them from an API perspective. Vector currently exposes enough (or at least almost enough) of the implementation details that such support could be implemented 'out-of-line' from the main library. (I think the Data.Vector.Primitive constructor is currently not exported, and you'd need that.) I don't *think* Roman would object too strenuously to exporting it though and I've personally wanted it for other reasons. This would open the door to this sort of thing being something you might supply entirely outside of the library, giving the final placement of the code some flexibility. You could handle CAS operations for Primitive and boxed Vectors pretty easily at least, leaving off Unboxed and my various hybrid vector approaches as they are intrinsically tied to working on multiple underlying source vectors. I'm pretty open to ideas about where the instances should live though. One argument for putting it in vector is you could extend Prim with the CAS operations directly rather than subclass it. An argument against is it could then iterate on a more flexible time table. -Edward On Thu, Nov 21, 2013 at 10:30 AM, Ryan Newton wrote: > [Popping up to the big-picture question for a moment, from the previous > thread on Vector CAS.] > > Given that a lot of people are really advertising Haskell on the > parallel/concurrent front, it seems like we *should* be committed as a > community to making our basic libraries support parallel/concurrent use > cases effectively. This will necessarily mean touching some core libraries > (container, vector...). > > The two things that have come up for me recently are (1) CAS/RMW on > [unboxed] Vectors and a general notion of balanced-splitting for tree-based > structures (Map,Set). But I'm sure there are others! > > Is any one else invested in getting this kind of thing moving? It would > be great to have a partner. I can commit a small amount of cycles, but I > don't have lots of bandwidth for non-research infrastructure work > presently. Edward, is any of this useful to you? > > In many of these cases it seems like the main problem is not a technical > one, but the social one of consensus building (and fighting excessive "stop > energy" if it appears). Edward, as chair of the core libraries committee, > maybe you could help with this? > > Cheers, > -Ryan > > > On Thu, Nov 21, 2013 at 10:25 AM, Ryan Newton wrote: > >> [@Aleksey] Very good point! I'd missed that vector does the SOA->AOS >> business too. (I thought that was just Repa & Accelerate.) >> >> In any case, an unboxed vector of tuples can't *actually* support atomic >> CAS anyway, so not supporting it is inevitable. >> It does mean that exposeMutableByteArray can't be a method of the >> Unbox class. It would need to be another class capturing the subset of >> vector types that are "Atomic" (support concurrent/atomic memory ops). >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Thu Nov 21 16:29:15 2013 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 21 Nov 2013 11:29:15 -0500 Subject: Who needs and wants parallelism-friendly core libs? In-Reply-To: References: Message-ID: Actually, the Primitive.Vector constructor should be irrelevant. Nevermind. It is the mutable one you need and that one is public. On Thu, Nov 21, 2013 at 11:11 AM, Edward Kmett wrote: > I'd like to hash this out a bit further. As this issue affects vector primarily, > it is outside of the scope of the core library committee per se, and is > largely up to Roman as the maintainer of vector. > > That said if I put on my personal and not my 'committee' hat: > > I would use these operations, personally, were they available to me. > > The question is how to best expose them from an API perspective. > > Vector currently exposes enough (or at least almost enough) of the > implementation details that such support could be implemented 'out-of-line' > from the main library. (I think the Data.Vector.Primitive constructor is > currently not exported, and you'd need that.) > > I don't *think* Roman would object too strenuously to exporting it though > and I've personally wanted it for other reasons. This would open the door > to this sort of thing being something you might supply entirely outside of > the library, giving the final placement of the code some flexibility. > > You could handle CAS operations for Primitive and boxed Vectors pretty > easily at least, leaving off Unboxed and my various hybrid vector > approaches as they are intrinsically tied to working on multiple underlying > source vectors. > > I'm pretty open to ideas about where the instances should live though. One > argument for putting it in vector is you could extend Prim with the CAS > operations directly rather than subclass it. An argument against is it > could then iterate on a more flexible time table. > > -Edward > > > On Thu, Nov 21, 2013 at 10:30 AM, Ryan Newton wrote: > >> [Popping up to the big-picture question for a moment, from the previous >> thread on Vector CAS.] >> >> Given that a lot of people are really advertising Haskell on the >> parallel/concurrent front, it seems like we *should* be committed as a >> community to making our basic libraries support parallel/concurrent use >> cases effectively. This will necessarily mean touching some core libraries >> (container, vector...). >> >> The two things that have come up for me recently are (1) CAS/RMW on >> [unboxed] Vectors and a general notion of balanced-splitting for tree-based >> structures (Map,Set). But I'm sure there are others! >> >> Is any one else invested in getting this kind of thing moving? It would >> be great to have a partner. I can commit a small amount of cycles, but I >> don't have lots of bandwidth for non-research infrastructure work >> presently. Edward, is any of this useful to you? >> >> In many of these cases it seems like the main problem is not a technical >> one, but the social one of consensus building (and fighting excessive "stop >> energy" if it appears). Edward, as chair of the core libraries committee, >> maybe you could help with this? >> >> Cheers, >> -Ryan >> >> >> On Thu, Nov 21, 2013 at 10:25 AM, Ryan Newton wrote: >> >>> [@Aleksey] Very good point! I'd missed that vector does the SOA->AOS >>> business too. (I thought that was just Repa & Accelerate.) >>> >>> In any case, an unboxed vector of tuples can't *actually* support >>> atomic CAS anyway, so not supporting it is inevitable. >>> It does mean that exposeMutableByteArray can't be a method of the >>> Unbox class. It would need to be another class capturing the subset of >>> vector types that are "Atomic" (support concurrent/atomic memory ops). >>> >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bos at serpentine.com Thu Nov 21 16:45:16 2013 From: bos at serpentine.com (Bryan O'Sullivan) Date: Thu, 21 Nov 2013 08:45:16 -0800 Subject: Who needs and wants parallelism-friendly core libs? In-Reply-To: References: Message-ID: On Thu, Nov 21, 2013 at 8:11 AM, Edward Kmett wrote: > I'd like to hash this out a bit further. As this issue affects vector primarily, > it is outside of the scope of the core library committee per se, and is > largely up to Roman as the maintainer of vector. > Remember that Roman has fairly explicitly resigned as the maintainer of vector for want of time, so someone else needs to take up the crusade here. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Thu Nov 21 16:53:41 2013 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 21 Nov 2013 11:53:41 -0500 Subject: Who needs and wants parallelism-friendly core libs? In-Reply-To: References: Message-ID: Fair enough. I had missed that fact! In that case, we could bring vector under the arm of the core libraries committee, or we could seek a more direct maintainer. [Adding Geoffrey Mainland to the To: list] Geoffrey, would you be willing to pick up maintainership? I mention it mostly because I know your recent SIMD work has been very vector-centric, and you are the person most likely to affect it's course in the near term. If not, I could pick it up personally, or we could put it under the core libraries committee. -Edward On Thu, Nov 21, 2013 at 11:45 AM, Bryan O'Sullivan wrote: > > On Thu, Nov 21, 2013 at 8:11 AM, Edward Kmett wrote: > >> I'd like to hash this out a bit further. As this issue affects vector primarily, >> it is outside of the scope of the core library committee per se, and is >> largely up to Roman as the maintainer of vector. >> > > Remember that Roman has fairly explicitly resigned as the maintainer of > vector for want of time, so someone else needs to take up the crusade here. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Nov 21 17:17:52 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 21 Nov 2013 12:17:52 -0500 Subject: Who needs and wants parallelism-friendly core libs? In-Reply-To: References: Message-ID: I'm willing to help out on vector, as I use it quite a lot! I've not done much contrib to it as yet, but I like to think I'm familiar with a good chunk of the code base and that I obsessively care about making sure array based computation in Haskell is a great experience. -carter On Thursday, November 21, 2013, Bryan O'Sullivan wrote: > > On Thu, Nov 21, 2013 at 8:11 AM, Edward Kmett > > wrote: > >> I'd like to hash this out a bit further. As this issue affects vector primarily, >> it is outside of the scope of the core library committee per se, and is >> largely up to Roman as the maintainer of vector. >> > > Remember that Roman has fairly explicitly resigned as the maintainer of > vector for want of time, so someone else needs to take up the crusade here. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwlato at gmail.com Thu Nov 21 17:47:52 2013 From: jwlato at gmail.com (John Lato) Date: Thu, 21 Nov 2013 09:47:52 -0800 Subject: Who needs and wants parallelism-friendly core libs? In-Reply-To: References: Message-ID: I'm also willing to help on vector, for the same reason as Carter. On Nov 21, 2013 9:18 AM, "Carter Schonwald" wrote: > I'm willing to help out on vector, as I use it quite a lot! I've not done > much contrib to it as yet, but I like to think I'm familiar with a good > chunk of the code base and that I obsessively care about making sure array > based computation in Haskell is a great experience. > > -carter > > On Thursday, November 21, 2013, Bryan O'Sullivan wrote: > >> >> On Thu, Nov 21, 2013 at 8:11 AM, Edward Kmett wrote: >> >>> I'd like to hash this out a bit further. As this issue affects vector primarily, >>> it is outside of the scope of the core library committee per se, and is >>> largely up to Roman as the maintainer of vector. >>> >> >> Remember that Roman has fairly explicitly resigned as the maintainer of >> vector for want of time, so someone else needs to take up the crusade here. >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rrnewton at gmail.com Thu Nov 21 19:05:49 2013 From: rrnewton at gmail.com (Ryan Newton) Date: Thu, 21 Nov 2013 14:05:49 -0500 Subject: Best way to get to CAS/fetch-and-add on unboxed vectors? In-Reply-To: References: Message-ID: I'm not sure why this would be a ticket, because it's not really a bug or an issue with GHC. But I did go ahead and write up the state of affairs in a Haskell wiki page here: http://www.haskell.org/haskellwiki/AtomicMemoryOps There's just a fundamental impedance mismatch between having a lazy/pure world where pointer equality is meaningless, and operations based on pointer-equality like CAS. I think we've papered over that as best we could with the "Ticketed" interface describe in that wiki, but I don't think there's anything else I could have asked of GHC to make this any easier. But as you know there are several improvements that can be made to make what we've got better. Are you blocked on anything wrt to adding direct LLVM support for the primops in question? On Wed, Nov 20, 2013 at 4:38 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > I though Vector instances had their constructors exported so that you can > get at the underlying Primitive vectors, and and Primitive vectors have a > bytearray underneath! > I don't understand why Vector/MVector needs to be changed here to support > that info. > For the Atomic operations, it seems like you just really want to only > support the operations on vector types directly expressable with Primitive > vectors. Perhaps i'm not understanding though. > As far as I can see if the user gives you a "Data.Vector.Unboxed.MVector s Int8", what you're getting is the result of this type function: newtype instance MVector s Int8 = MV_Int8 (P.MVector s Int8) .. from Unboxed.Base.hs. The only thing that's provided for "MVector s a" types generally are instances of the Vector/MVector classes, which don't say how to get the pointer(s). BUT... you make a good point about the constructors (e.g. MV_Int8) being exposed! It seems like we CAN make our own type family that mirrors the MVector one, and which leverages *each* of those "newtype instance" equations, matching on an MV_Int8 and grabbing the underlying Primitive vector... Nice! On Wed, Nov 20, 2013 at 10:57 AM, Ryan Newton wrote: > >> We do expose CAS for boxed data, and we depend on that for various >> concurrent data structures (e.g. Michael-scott queues). >> >> But it's a messy business: >> >> You have to fight hard against the GHC optimizer to prevent >> it from performing optimizations (e.g. unbox and rebox an Int) that >> completely destroy pointer equality (in all runs of the program). The way >> that we've codified our solution to this is to use abstract "Ticket"s >> (based on the Any kind) that GHC is not supposed to be able to see through. >> These are used to abstractly represent old reads when you come back to do >> a new CAS operation: >> >> >> http://hackage.haskell.org/package/atomic-primops-0.4/docs/Data-Atomics.html#g:2 >> >> Even then, there was a bunch of careful NOINLINE's and other business >> necessary to achieve something workable, and it's highly GHC specific. If >> we were to expose CAS on boxed "Data.Vector", I think it would only make >> sense as the ticketed interface above (raw CAS is useless, and will just >> condemn others to the same problems we had). >> >> >> As a result of all this the CAS for Data.Vector would have a different >> signature (unless we wanted to force Storable/Unbox to use Tickets), and >> thus couldn't go in the "MVector" type class along with all the other basic >> operations that are uniform across representations. >> >> That said, it's easy to provide CAS from a separate "vector-atomics" >> package, because Data.Vector exposes the MVector constructor that lets you >> get at the underlying MutableArray. So we certainly can provide the >> functionality somewhere, somehow. >> >> -Ryan >> >> >> >> On Wed, Nov 20, 2013 at 10:21 AM, Jan-Willem Maessen < >> jmaessen at alum.mit.edu> wrote: >> >>> On Wed, Nov 20, 2013 at 10:06 AM, Ryan Newton wrote: >>> >>>> (3) The most invasive (but best for the user) change would be to extend >>>> the basic MVector interface to include notions of concurrency-related >>>> operations right inside the vector package (CAS, etc). But they should >>>> still probably go in a separate class (not class MVector), just because >>>> they will be specific to Unboxed and Storable vectors rather than boxed >>>> ones.... >>>> >>> >>> Any reason we shouldn't be able to CAS on boxed vectors? Every >>> architecture supports a pointer-sized CAS. What "equality" means for CAS, >>> of course, has to be rather carefully defined, but that's equally true for >>> the unboxed types. >>> >>> -Jan >>> >>> >>>> >>>> -Ryan >>>> >>>> >>>> _______________________________________________ >>>> 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 mail at joachim-breitner.de Thu Nov 21 19:30:27 2013 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 21 Nov 2013 19:30:27 +0000 Subject: Proposal: add fusion RULES for Data.Map.mapMaybe In-Reply-To: References: Message-ID: <1385062227.26867.0.camel@kirk> Hi, Am Mittwoch, den 20.11.2013, 16:40 +0900 schrieb Akio Takano: > Currently mapMaybe does not fuse at all. The attached patch implements > necessary rules for fold/build fusion in both sides (the result and > the second argument) to happen. When fusion does not happen, the > function should behave exactly the same as before. +1. Also, the code seems to be correct (at least quickcheck tells me so). Thanks for the contribution, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From carter.schonwald at gmail.com Thu Nov 21 19:33:41 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 21 Nov 2013 14:33:41 -0500 Subject: Best way to get to CAS/fetch-and-add on unboxed vectors? In-Reply-To: References: Message-ID: nothing blocking adding the primops right now from a technical standpoint (though it'd be too late for the 7.8 merge window). The main blocker is i'm moving over the next month + I'm amidst sorting transitioning from consulting to some other work. (life and all). i want to also add the inline primops to the native code gen and -fvia-c in tandem with baking in the LLVM support. Which will take a teeny bit of extra work, but really very much worth it I think. Glad you agree about the constructors being handy! Should make is possible to have the CAS vector stuff working as a selfcontained experiment that just works ? with current vector. On Thu, Nov 21, 2013 at 2:05 PM, Ryan Newton wrote: > I'm not sure why this would be a ticket, because it's not really a bug or > an issue with GHC. But I did go ahead and write up the state of affairs in > a Haskell wiki page here: > > http://www.haskell.org/haskellwiki/AtomicMemoryOps > > There's just a fundamental impedance mismatch between having a lazy/pure > world where pointer equality is meaningless, and operations based on > pointer-equality like CAS. I think we've papered over that as best we > could with the "Ticketed" interface describe in that wiki, but I don't > think there's anything else I could have asked of GHC to make this any > easier. > > But as you know there are several improvements that can be made to make > what we've got better. Are you blocked on anything wrt to adding direct > LLVM support for the primops in question? > > On Wed, Nov 20, 2013 at 4:38 PM, Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> I though Vector instances had their constructors exported so that you can >> get at the underlying Primitive vectors, and and Primitive vectors have a >> bytearray underneath! >> I don't understand why Vector/MVector needs to be changed here to support >> that info. >> For the Atomic operations, it seems like you just really want to only >> support the operations on vector types directly expressable with Primitive >> vectors. Perhaps i'm not understanding though. >> > > As far as I can see if the user gives you a "Data.Vector.Unboxed.MVector s > Int8", what you're getting is the result of this type function: > > newtype instance MVector s Int8 = MV_Int8 (P.MVector s Int8) > > .. from Unboxed.Base.hs. The only thing that's provided for "MVector s a" > types generally are instances of the Vector/MVector classes, which don't > say how to get the pointer(s). > > BUT... you make a good point about the constructors (e.g. MV_Int8) being > exposed! It seems like we CAN make our own type family that mirrors the > MVector one, and which leverages *each* of those "newtype instance" > equations, matching on an MV_Int8 and grabbing the underlying Primitive > vector... Nice! > > > > > On Wed, Nov 20, 2013 at 10:57 AM, Ryan Newton wrote: >> >>> We do expose CAS for boxed data, and we depend on that for various >>> concurrent data structures (e.g. Michael-scott queues). >>> >>> But it's a messy business: >>> >>> You have to fight hard against the GHC optimizer to >>> prevent it from performing optimizations (e.g. unbox and rebox an Int) that >>> completely destroy pointer equality (in all runs of the program). The way >>> that we've codified our solution to this is to use abstract "Ticket"s >>> (based on the Any kind) that GHC is not supposed to be able to see through. >>> These are used to abstractly represent old reads when you come back to do >>> a new CAS operation: >>> >>> >>> http://hackage.haskell.org/package/atomic-primops-0.4/docs/Data-Atomics.html#g:2 >>> >>> Even then, there was a bunch of careful NOINLINE's and other business >>> necessary to achieve something workable, and it's highly GHC specific. If >>> we were to expose CAS on boxed "Data.Vector", I think it would only make >>> sense as the ticketed interface above (raw CAS is useless, and will just >>> condemn others to the same problems we had). >>> >>> >>> As a result of all this the CAS for Data.Vector would have a different >>> signature (unless we wanted to force Storable/Unbox to use Tickets), and >>> thus couldn't go in the "MVector" type class along with all the other basic >>> operations that are uniform across representations. >>> >>> That said, it's easy to provide CAS from a separate "vector-atomics" >>> package, because Data.Vector exposes the MVector constructor that lets you >>> get at the underlying MutableArray. So we certainly can provide the >>> functionality somewhere, somehow. >>> >>> -Ryan >>> >>> >>> >>> On Wed, Nov 20, 2013 at 10:21 AM, Jan-Willem Maessen < >>> jmaessen at alum.mit.edu> wrote: >>> >>>> On Wed, Nov 20, 2013 at 10:06 AM, Ryan Newton wrote: >>>> >>>>> (3) The most invasive (but best for the user) change would be to >>>>> extend the basic MVector interface to include notions of >>>>> concurrency-related operations right inside the vector package (CAS, etc). >>>>> But they should still probably go in a separate class (not class MVector), >>>>> just because they will be specific to Unboxed and Storable vectors rather >>>>> than boxed ones.... >>>>> >>>> >>>> Any reason we shouldn't be able to CAS on boxed vectors? Every >>>> architecture supports a pointer-sized CAS. What "equality" means for CAS, >>>> of course, has to be rather carefully defined, but that's equally true for >>>> the unboxed types. >>>> >>>> -Jan >>>> >>>> >>>>> >>>>> -Ryan >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 ashley at semantic.org Thu Nov 21 20:21:27 2013 From: ashley at semantic.org (Ashley Yakeley) Date: Thu, 21 Nov 2013 12:21:27 -0800 Subject: System.Posix.IO.ByteString fdRead and fdWrite. In-Reply-To: <528DE6A8.80103@gmail.com> References: <87a9gyrwvx.fsf@gnu.org> <528DE6A8.80103@gmail.com> Message-ID: <528E6B47.8020908@semantic.org> On 2013-11-21 02:55, Simon Marlow wrote: >> However, I'm not totally sure from that, whether the type-sigs >> >> >> fdRead :: Fd >> -> ByteCount -- ^How many bytes to read >> -> IO (String, ByteCount) -- ^ The bytes read, how many bytes >> were read. >> >> fdWrite :: Fd -> String -> IO ByteCount >> >> >> were really intended to be that way. >> >> Simon, maybe you can provide some insight here? > > Brandon's reply is correct, the ByteString variant of the POSIX API is > intended to change the representation of file paths only. > > These two functions are totally useless and we need better versions anyway. Regarding the path type issue, I wonder if it wouldn't be easier to settle on something like newtype PosixFilePath = PosixFilePath ByteString instance IsString PosixFilePath where ... -- Ashley From ekmett at gmail.com Thu Nov 21 20:28:27 2013 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 21 Nov 2013 15:28:27 -0500 Subject: [core libraries] Proposal: add fusion RULES for Data.Map.mapMaybe In-Reply-To: References: Message-ID: +1 Makes sense to me. -Edward On Wed, Nov 20, 2013 at 2:40 AM, Akio Takano wrote: > Hi, > > Currently mapMaybe does not fuse at all. The attached patch implements > necessary rules for fold/build fusion in both sides (the result and the > second argument) to happen. When fusion does not happen, the function > should behave exactly the same as before. > > I ran some benchmarks, testing cases where fusion does and does not happen: > > > http://htmlpreview.github.io/?https://github.com/takano-akio/mapmaybe-benchmarks/blob/master/out.html > > The benchmark code is: > > https://github.com/takano-akio/mapmaybe-benchmarks/blob/master/main.hs > > Discussion period: 2 weeks. > > Thank you, > Takano Akio > > -- > You received this message because you are subscribed to the Google Groups > "haskell-core-libraries" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to haskell-core-libraries+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rrnewton at gmail.com Thu Nov 21 21:00:08 2013 From: rrnewton at gmail.com (Ryan Newton) Date: Thu, 21 Nov 2013 16:00:08 -0500 Subject: Who needs and wants parallelism-friendly core libs? In-Reply-To: References: Message-ID: Yep, it is public! So it is fine to do this to rip the MutableByteArray out of the relevant "MVector s a" types: https://github.com/rrnewton/haskell-lockfree/blob/cc2690f96ed616f9d1221770c5213d1ae41facc9/vector-atomics/Data/Vector/Unboxed/Atomic.hs And then we can build up a "vector-atomics" package that exposes all the relevant ops on [un]boxed vectors (and Storable too if we want to use the bits-atomic package). Personally, right this moment I need fetch-and-OR and fetch-and-AND because I want a concurrent hierarchical bit-vector for storing subsets of the integers [0,N). Edward, I don't suppose you have that one up your sleeve already ;-)? -Ryan On Thu, Nov 21, 2013 at 11:29 AM, Edward Kmett wrote: > Actually, the Primitive.Vector constructor should be irrelevant. > Nevermind. It is the mutable one you need and that one is public. > > > On Thu, Nov 21, 2013 at 11:11 AM, Edward Kmett wrote: > >> I'd like to hash this out a bit further. As this issue affects vector primarily, >> it is outside of the scope of the core library committee per se, and is >> largely up to Roman as the maintainer of vector. >> >> That said if I put on my personal and not my 'committee' hat: >> >> I would use these operations, personally, were they available to me. >> >> The question is how to best expose them from an API perspective. >> >> Vector currently exposes enough (or at least almost enough) of the >> implementation details that such support could be implemented 'out-of-line' >> from the main library. (I think the Data.Vector.Primitive constructor is >> currently not exported, and you'd need that.) >> >> I don't *think* Roman would object too strenuously to exporting it >> though and I've personally wanted it for other reasons. This would open the >> door to this sort of thing being something you might supply entirely >> outside of the library, giving the final placement of the code some >> flexibility. >> >> You could handle CAS operations for Primitive and boxed Vectors pretty >> easily at least, leaving off Unboxed and my various hybrid vector >> approaches as they are intrinsically tied to working on multiple underlying >> source vectors. >> >> I'm pretty open to ideas about where the instances should live though. >> One argument for putting it in vector is you could extend Prim with the CAS >> operations directly rather than subclass it. An argument against is it >> could then iterate on a more flexible time table. >> >> -Edward >> >> >> On Thu, Nov 21, 2013 at 10:30 AM, Ryan Newton wrote: >> >>> [Popping up to the big-picture question for a moment, from the previous >>> thread on Vector CAS.] >>> >>> Given that a lot of people are really advertising Haskell on the >>> parallel/concurrent front, it seems like we *should* be committed as a >>> community to making our basic libraries support parallel/concurrent use >>> cases effectively. This will necessarily mean touching some core libraries >>> (container, vector...). >>> >>> The two things that have come up for me recently are (1) CAS/RMW on >>> [unboxed] Vectors and a general notion of balanced-splitting for tree-based >>> structures (Map,Set). But I'm sure there are others! >>> >>> Is any one else invested in getting this kind of thing moving? It would >>> be great to have a partner. I can commit a small amount of cycles, but I >>> don't have lots of bandwidth for non-research infrastructure work >>> presently. Edward, is any of this useful to you? >>> >>> In many of these cases it seems like the main problem is not a technical >>> one, but the social one of consensus building (and fighting excessive "stop >>> energy" if it appears). Edward, as chair of the core libraries committee, >>> maybe you could help with this? >>> >>> Cheers, >>> -Ryan >>> >>> >>> On Thu, Nov 21, 2013 at 10:25 AM, Ryan Newton wrote: >>> >>>> [@Aleksey] Very good point! I'd missed that vector does the SOA->AOS >>>> business too. (I thought that was just Repa & Accelerate.) >>>> >>>> In any case, an unboxed vector of tuples can't *actually* support >>>> atomic CAS anyway, so not supporting it is inevitable. >>>> It does mean that exposeMutableByteArray can't be a method of the >>>> Unbox class. It would need to be another class capturing the subset of >>>> vector types that are "Atomic" (support concurrent/atomic memory ops). >>>> >>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Nov 21 21:24:23 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 21 Nov 2013 16:24:23 -0500 Subject: Who needs and wants parallelism-friendly core libs? In-Reply-To: References: Message-ID: hehe, those are some of the other operations that llvm would let us write pretty easily! Do we have those on the inline atomics ticket? if not could you add those and any other ideas there? https://ghc.haskell.org/trac/ghc/ticket/7883 @ryan, as a stopgap, wouldn't just wrapping some unsafe ffi c calls around the analogous C intrinsics get you those primops? Its really easy to go back and forth between the types Ptr a and Addr# (after all, data Ptr a = Ptr Addr# !) cheers -Carter On Thu, Nov 21, 2013 at 4:00 PM, Ryan Newton wrote: > Yep, it is public! So it is fine to do this to rip the MutableByteArray > out of the relevant "MVector s a" types: > > > https://github.com/rrnewton/haskell-lockfree/blob/cc2690f96ed616f9d1221770c5213d1ae41facc9/vector-atomics/Data/Vector/Unboxed/Atomic.hs > > And then we can build up a "vector-atomics" package that exposes all the > relevant ops on [un]boxed vectors (and Storable too if we want to use the > bits-atomic package). > > Personally, right this moment I need fetch-and-OR and fetch-and-AND > because I want a concurrent hierarchical bit-vector for storing subsets of > the integers [0,N). Edward, I don't suppose you have that one up your > sleeve already ;-)? > > -Ryan > > > > On Thu, Nov 21, 2013 at 11:29 AM, Edward Kmett wrote: > >> Actually, the Primitive.Vector constructor should be irrelevant. >> Nevermind. It is the mutable one you need and that one is public. >> >> >> On Thu, Nov 21, 2013 at 11:11 AM, Edward Kmett wrote: >> >>> I'd like to hash this out a bit further. As this issue affects vector primarily, >>> it is outside of the scope of the core library committee per se, and is >>> largely up to Roman as the maintainer of vector. >>> >>> That said if I put on my personal and not my 'committee' hat: >>> >>> I would use these operations, personally, were they available to me. >>> >>> The question is how to best expose them from an API perspective. >>> >>> Vector currently exposes enough (or at least almost enough) of the >>> implementation details that such support could be implemented 'out-of-line' >>> from the main library. (I think the Data.Vector.Primitive constructor is >>> currently not exported, and you'd need that.) >>> >>> I don't *think* Roman would object too strenuously to exporting it >>> though and I've personally wanted it for other reasons. This would open the >>> door to this sort of thing being something you might supply entirely >>> outside of the library, giving the final placement of the code some >>> flexibility. >>> >>> You could handle CAS operations for Primitive and boxed Vectors pretty >>> easily at least, leaving off Unboxed and my various hybrid vector >>> approaches as they are intrinsically tied to working on multiple underlying >>> source vectors. >>> >>> I'm pretty open to ideas about where the instances should live though. >>> One argument for putting it in vector is you could extend Prim with the CAS >>> operations directly rather than subclass it. An argument against is it >>> could then iterate on a more flexible time table. >>> >>> -Edward >>> >>> >>> On Thu, Nov 21, 2013 at 10:30 AM, Ryan Newton wrote: >>> >>>> [Popping up to the big-picture question for a moment, from the previous >>>> thread on Vector CAS.] >>>> >>>> Given that a lot of people are really advertising Haskell on the >>>> parallel/concurrent front, it seems like we *should* be committed as a >>>> community to making our basic libraries support parallel/concurrent use >>>> cases effectively. This will necessarily mean touching some core libraries >>>> (container, vector...). >>>> >>>> The two things that have come up for me recently are (1) CAS/RMW on >>>> [unboxed] Vectors and a general notion of balanced-splitting for tree-based >>>> structures (Map,Set). But I'm sure there are others! >>>> >>>> Is any one else invested in getting this kind of thing moving? It >>>> would be great to have a partner. I can commit a small amount of cycles, >>>> but I don't have lots of bandwidth for non-research infrastructure work >>>> presently. Edward, is any of this useful to you? >>>> >>>> In many of these cases it seems like the main problem is not a >>>> technical one, but the social one of consensus building (and fighting >>>> excessive "stop energy" if it appears). Edward, as chair of the core >>>> libraries committee, maybe you could help with this? >>>> >>>> Cheers, >>>> -Ryan >>>> >>>> >>>> On Thu, Nov 21, 2013 at 10:25 AM, Ryan Newton wrote: >>>> >>>>> [@Aleksey] Very good point! I'd missed that vector does the SOA->AOS >>>>> business too. (I thought that was just Repa & Accelerate.) >>>>> >>>>> In any case, an unboxed vector of tuples can't *actually* support >>>>> atomic CAS anyway, so not supporting it is inevitable. >>>>> It does mean that exposeMutableByteArray can't be a method of the >>>>> Unbox class. It would need to be another class capturing the subset of >>>>> vector types that are "Atomic" (support concurrent/atomic memory ops). >>>>> >>>>> >>>>> >>>>> >>>> >>> >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Thu Nov 21 23:37:29 2013 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 21 Nov 2013 18:37:29 -0500 Subject: Who needs and wants parallelism-friendly core libs? In-Reply-To: References: Message-ID: I have several bit-vector variants floating around in various side-projects, such as github.com/ekmett/succinct and github.com/ekmett/structures but I don't currently have HBVs per se. I have some code that rolls up aggregations by that same complete tree structure though to build range-min-max trees and the like. On Thu, Nov 21, 2013 at 4:00 PM, Ryan Newton wrote: > Yep, it is public! So it is fine to do this to rip the MutableByteArray > out of the relevant "MVector s a" types: > > > https://github.com/rrnewton/haskell-lockfree/blob/cc2690f96ed616f9d1221770c5213d1ae41facc9/vector-atomics/Data/Vector/Unboxed/Atomic.hs > > And then we can build up a "vector-atomics" package that exposes all the > relevant ops on [un]boxed vectors (and Storable too if we want to use the > bits-atomic package). > > Personally, right this moment I need fetch-and-OR and fetch-and-AND > because I want a concurrent hierarchical bit-vector for storing subsets of > the integers [0,N). Edward, I don't suppose you have that one up your > sleeve already ;-)? > > -Ryan > > > > On Thu, Nov 21, 2013 at 11:29 AM, Edward Kmett wrote: > >> Actually, the Primitive.Vector constructor should be irrelevant. >> Nevermind. It is the mutable one you need and that one is public. >> >> >> On Thu, Nov 21, 2013 at 11:11 AM, Edward Kmett wrote: >> >>> I'd like to hash this out a bit further. As this issue affects vector primarily, >>> it is outside of the scope of the core library committee per se, and is >>> largely up to Roman as the maintainer of vector. >>> >>> That said if I put on my personal and not my 'committee' hat: >>> >>> I would use these operations, personally, were they available to me. >>> >>> The question is how to best expose them from an API perspective. >>> >>> Vector currently exposes enough (or at least almost enough) of the >>> implementation details that such support could be implemented 'out-of-line' >>> from the main library. (I think the Data.Vector.Primitive constructor is >>> currently not exported, and you'd need that.) >>> >>> I don't *think* Roman would object too strenuously to exporting it >>> though and I've personally wanted it for other reasons. This would open the >>> door to this sort of thing being something you might supply entirely >>> outside of the library, giving the final placement of the code some >>> flexibility. >>> >>> You could handle CAS operations for Primitive and boxed Vectors pretty >>> easily at least, leaving off Unboxed and my various hybrid vector >>> approaches as they are intrinsically tied to working on multiple underlying >>> source vectors. >>> >>> I'm pretty open to ideas about where the instances should live though. >>> One argument for putting it in vector is you could extend Prim with the CAS >>> operations directly rather than subclass it. An argument against is it >>> could then iterate on a more flexible time table. >>> >>> -Edward >>> >>> >>> On Thu, Nov 21, 2013 at 10:30 AM, Ryan Newton wrote: >>> >>>> [Popping up to the big-picture question for a moment, from the previous >>>> thread on Vector CAS.] >>>> >>>> Given that a lot of people are really advertising Haskell on the >>>> parallel/concurrent front, it seems like we *should* be committed as a >>>> community to making our basic libraries support parallel/concurrent use >>>> cases effectively. This will necessarily mean touching some core libraries >>>> (container, vector...). >>>> >>>> The two things that have come up for me recently are (1) CAS/RMW on >>>> [unboxed] Vectors and a general notion of balanced-splitting for tree-based >>>> structures (Map,Set). But I'm sure there are others! >>>> >>>> Is any one else invested in getting this kind of thing moving? It >>>> would be great to have a partner. I can commit a small amount of cycles, >>>> but I don't have lots of bandwidth for non-research infrastructure work >>>> presently. Edward, is any of this useful to you? >>>> >>>> In many of these cases it seems like the main problem is not a >>>> technical one, but the social one of consensus building (and fighting >>>> excessive "stop energy" if it appears). Edward, as chair of the core >>>> libraries committee, maybe you could help with this? >>>> >>>> Cheers, >>>> -Ryan >>>> >>>> >>>> On Thu, Nov 21, 2013 at 10:25 AM, Ryan Newton wrote: >>>> >>>>> [@Aleksey] Very good point! I'd missed that vector does the SOA->AOS >>>>> business too. (I thought that was just Repa & Accelerate.) >>>>> >>>>> In any case, an unboxed vector of tuples can't *actually* support >>>>> atomic CAS anyway, so not supporting it is inevitable. >>>>> It does mean that exposeMutableByteArray can't be a method of the >>>>> Unbox class. It would need to be another class capturing the subset of >>>>> vector types that are "Atomic" (support concurrent/atomic memory ops). >>>>> >>>>> >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Fri Nov 22 00:00:54 2013 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 21 Nov 2013 19:00:54 -0500 Subject: Who needs and wants parallelism-friendly core libs? In-Reply-To: References: Message-ID: Since vector is needed to build ghc with dph, and has gone fallow, I suppose it really does need a maintainer. I've personally spent a lot of time mucking around in its internals building hybrid-vector and vector-instances and many of my recent projects center on the guts of vector. To that end, I've forked vector over to my github account. If nobody has any objections, we can use that as a sort of staging ground for this sort of change before they filter up to the main repository. I'm happy to juggle whatever integration work is required as an individual maintainer, or to work through the committee if folks really prefer, just to make sure everything continues to work well, but I think things like the recent change to SPEC in HEAD, future SIMD integration via generalized stream fusion using Geoffrey's work, and this CAS proposal will require somewhat active management. That said, if someone else feels strongly about wanting to take over maintainership personally (Geoff?), I'm happy to have the conversation. -Edward On Thu, Nov 21, 2013 at 6:37 PM, Edward Kmett wrote: > I have several bit-vector variants floating around in various > side-projects, such as github.com/ekmett/succinct and > github.com/ekmett/structures but I don't currently have HBVs per se. I > have some code that rolls up aggregations by that same complete tree > structure though to build range-min-max trees and the like. > > > On Thu, Nov 21, 2013 at 4:00 PM, Ryan Newton wrote: > >> Yep, it is public! So it is fine to do this to rip the MutableByteArray >> out of the relevant "MVector s a" types: >> >> >> https://github.com/rrnewton/haskell-lockfree/blob/cc2690f96ed616f9d1221770c5213d1ae41facc9/vector-atomics/Data/Vector/Unboxed/Atomic.hs >> >> And then we can build up a "vector-atomics" package that exposes all the >> relevant ops on [un]boxed vectors (and Storable too if we want to use the >> bits-atomic package). >> >> Personally, right this moment I need fetch-and-OR and fetch-and-AND >> because I want a concurrent hierarchical bit-vector for storing subsets of >> the integers [0,N). Edward, I don't suppose you have that one up your >> sleeve already ;-)? >> >> -Ryan >> >> >> >> On Thu, Nov 21, 2013 at 11:29 AM, Edward Kmett wrote: >> >>> Actually, the Primitive.Vector constructor should be irrelevant. >>> Nevermind. It is the mutable one you need and that one is public. >>> >>> >>> On Thu, Nov 21, 2013 at 11:11 AM, Edward Kmett wrote: >>> >>>> I'd like to hash this out a bit further. As this issue affects vector primarily, >>>> it is outside of the scope of the core library committee per se, and is >>>> largely up to Roman as the maintainer of vector. >>>> >>>> That said if I put on my personal and not my 'committee' hat: >>>> >>>> I would use these operations, personally, were they available to me. >>>> >>>> The question is how to best expose them from an API perspective. >>>> >>>> Vector currently exposes enough (or at least almost enough) of the >>>> implementation details that such support could be implemented 'out-of-line' >>>> from the main library. (I think the Data.Vector.Primitive constructor is >>>> currently not exported, and you'd need that.) >>>> >>>> I don't *think* Roman would object too strenuously to exporting it >>>> though and I've personally wanted it for other reasons. This would open the >>>> door to this sort of thing being something you might supply entirely >>>> outside of the library, giving the final placement of the code some >>>> flexibility. >>>> >>>> You could handle CAS operations for Primitive and boxed Vectors pretty >>>> easily at least, leaving off Unboxed and my various hybrid vector >>>> approaches as they are intrinsically tied to working on multiple underlying >>>> source vectors. >>>> >>>> I'm pretty open to ideas about where the instances should live though. >>>> One argument for putting it in vector is you could extend Prim with the CAS >>>> operations directly rather than subclass it. An argument against is it >>>> could then iterate on a more flexible time table. >>>> >>>> -Edward >>>> >>>> >>>> On Thu, Nov 21, 2013 at 10:30 AM, Ryan Newton wrote: >>>> >>>>> [Popping up to the big-picture question for a moment, from the >>>>> previous thread on Vector CAS.] >>>>> >>>>> Given that a lot of people are really advertising Haskell on the >>>>> parallel/concurrent front, it seems like we *should* be committed as >>>>> a community to making our basic libraries support parallel/concurrent use >>>>> cases effectively. This will necessarily mean touching some core libraries >>>>> (container, vector...). >>>>> >>>>> The two things that have come up for me recently are (1) CAS/RMW on >>>>> [unboxed] Vectors and a general notion of balanced-splitting for tree-based >>>>> structures (Map,Set). But I'm sure there are others! >>>>> >>>>> Is any one else invested in getting this kind of thing moving? It >>>>> would be great to have a partner. I can commit a small amount of cycles, >>>>> but I don't have lots of bandwidth for non-research infrastructure work >>>>> presently. Edward, is any of this useful to you? >>>>> >>>>> In many of these cases it seems like the main problem is not a >>>>> technical one, but the social one of consensus building (and fighting >>>>> excessive "stop energy" if it appears). Edward, as chair of the core >>>>> libraries committee, maybe you could help with this? >>>>> >>>>> Cheers, >>>>> -Ryan >>>>> >>>>> >>>>> On Thu, Nov 21, 2013 at 10:25 AM, Ryan Newton wrote: >>>>> >>>>>> [@Aleksey] Very good point! I'd missed that vector does the SOA->AOS >>>>>> business too. (I thought that was just Repa & Accelerate.) >>>>>> >>>>>> In any case, an unboxed vector of tuples can't *actually* support >>>>>> atomic CAS anyway, so not supporting it is inevitable. >>>>>> It does mean that exposeMutableByteArray can't be a method of the >>>>>> Unbox class. It would need to be another class capturing the subset of >>>>>> vector types that are "Atomic" (support concurrent/atomic memory ops). >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bos at serpentine.com Fri Nov 22 00:04:53 2013 From: bos at serpentine.com (Bryan O'Sullivan) Date: Thu, 21 Nov 2013 16:04:53 -0800 Subject: Who needs and wants parallelism-friendly core libs? In-Reply-To: References: Message-ID: On Thu, Nov 21, 2013 at 4:00 PM, Edward Kmett wrote: > If nobody has any objections, we can use that as a sort of staging ground > for this sort of change before they filter up to the main repository. > I don't have a problem with you working on vector, but why wouldn't you just stage stuff on a branch in the main repo? If you do it in your own repo, that makes it effectively invisible to other people. -------------- next part -------------- An HTML attachment was scrubbed... URL: From reiddraper at gmail.com Fri Nov 22 00:27:16 2013 From: reiddraper at gmail.com (Reid Draper) Date: Thu, 21 Nov 2013 18:27:16 -0600 Subject: Proposal: free shrinking with QuickCheck Message-ID: I originally sent this message to the QuickCheck mailing list, but haven't heard anything in a while, and realized there are only ten subscribers. Below is the original message, any feedback appreciated. --- I have an idea to eliminate the `shrink` function from the `Arbitrary` type class. Currently, users can optionally implement shrinking manually, this tends to be boilerplate code and is "...clearly a generic programming problem" [1]. Further, users often have to create separate types to accommodate their domain's restrictions. For example, a user may wish to only generate power-of-two numbers for their test. Their code simply uses `Int`, but with QuickCheck they must create a `newtype` wrapper and implement this logic in both the `arbitrary` and `shrink` implementation. My idea is to eliminate the `shrink` function, and to integrate shrinking with the `arbitrary` function. Currently, the type for `arbitrary` is: arbitrary :: Gen a and `Gen` has the definition: newtype Gen a = MkGen{ unGen :: StdGen -> Int -> a } I suggest that instead of the inner-function returning `a`s, it should return `RoseTree a`. The root of the tree is the generated value, and the rest of the tree is all of the ways to shrink the value. Here's how things would fit together: data RoseTree a = RoseTree a [RoseTree a] -- this is the same as the current Gen newtype Generator a = Gen { unGen :: StdGen -> Int -> a } newtype Gen a = MkGen { unGen :: Gen (RoseTree a) } Conveniently, `Gen` still has a unary type constructor of `a`. Further, if users have implemented their `arbitrary` implementations in terms of the QuickCheck combinators, their code won't have to change at all (I don't think?). The lower-level combinators would be updated to manipulate trees, with functions like `joinRose` and `filterRose`. Let's next look at how `Gen` would implement the monad type class: instance Monad Gen where return = MkGen . return . return gen >>= f = MkGen $ helper (unGen gen) (unGen . f) -- sequence is from Data.Traversable where helper m k = m >>= \y -> fmap joinRose $ sequence $ fmap k y The implementation of `return` is clear. `>>=` isn't too bad either: the function provided to bind will return `Gen b`'s, and `joinRose` and `sequence` help us pull this `Generator (RoseTree b))` 'out', much like `join` does. This means our users can still write code like: (arbitrary :: Gen [Int]) >>= elements Which brings up a good point. The above code has an issue, `elements` is a partial function with respect to the empty list. With the current implementation, we'd use the `NonEmptyList` modifier, which much respect this predicate both during generation and shrinking. This change would allow all predicates to be expressed simply with `suchThat`, which, since it acts on both values _and_ shrink trees, applies the predicate in both places. The implementation of `suchThat` would have to unwrap `Gen`, and apply `roseFilter` to the `RoseTree` inside of `Generator`, using `fmap`. I have implemented the above description in my Clojure port of QuickCheck, called simple-check [1], and it seems to be working quite nicely. Further, I suspect Erlang QuickCheck [3] is doing something similar, though their implementation is not open source, I can't presume too much. Clearly this would be a big change, and my goal now is simply to start a discussion: how does this sound? What's wrong, what's likely to break? Feedback and criticism welcome. Reid [1] Scrap your boilerplate with class: extensible generic functions: http://research.microsoft.com/pubs/67439/gmap3.pdf [2] https://github.com/reiddraper/simple-check [3] http://www.quviq.com/index.html From ekmett at gmail.com Fri Nov 22 00:31:40 2013 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 21 Nov 2013 19:31:40 -0500 Subject: Who needs and wants parallelism-friendly core libs? In-Reply-To: References: Message-ID: I'm happy to do that as well if you feel strongly, it just requires more administrivia to coordinate, and the network graph on github shows the activity across repositories anyways, so I tend to work by fork and pull request, as I'm much more comfortable collapsing history on a repository off to on side than I am on the official repo. *shrug* -Edward On Thu, Nov 21, 2013 at 7:04 PM, Bryan O'Sullivan wrote: > > On Thu, Nov 21, 2013 at 4:00 PM, Edward Kmett wrote: > >> If nobody has any objections, we can use that as a sort of staging ground >> for this sort of change before they filter up to the main repository. >> > > I don't have a problem with you working on vector, but why wouldn't you > just stage stuff on a branch in the main repo? If you do it in your own > repo, that makes it effectively invisible to other people. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Nov 22 01:05:09 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 21 Nov 2013 20:05:09 -0500 Subject: Proposal: free shrinking with QuickCheck In-Reply-To: References: Message-ID: alternatively, would it be possible to have a default definition of shrink using generics? (I'm still chewing on your email, but sounds like the current definition doesn't have a default generic method!) On Thu, Nov 21, 2013 at 7:27 PM, Reid Draper wrote: > I originally sent this message to the QuickCheck mailing list, > but haven't heard anything in a while, and realized there are > only ten subscribers. Below is the original message, any feedback > appreciated. > > --- > > I have an idea to eliminate the `shrink` function from the `Arbitrary` type > class. Currently, users can optionally implement shrinking manually, this > tends > to be boilerplate code and is "...clearly a generic programming problem" > [1]. > Further, users often have to create separate types to accommodate their > domain's restrictions. For example, a user may wish to only generate > power-of-two numbers for their test. Their code simply uses `Int`, but with > QuickCheck they must create a `newtype` wrapper and implement this logic in > both the `arbitrary` and `shrink` implementation. My idea is to > eliminate the `shrink` function, and to integrate shrinking with the > `arbitrary` function. Currently, the type for `arbitrary` is: > > > arbitrary :: Gen a > > > and `Gen` has the definition: > > > newtype Gen a = MkGen{ unGen :: StdGen -> Int -> a } > > > I suggest that instead of the inner-function returning `a`s, it should > return > `RoseTree a`. The root of the tree is the generated value, and the rest of > the > tree is all of the ways to shrink the value. Here's how things would fit > together: > > > data RoseTree a = RoseTree a [RoseTree a] > > -- this is the same as the current Gen > newtype Generator a = Gen { unGen :: StdGen -> Int -> a } > > newtype Gen a = MkGen { unGen :: Gen (RoseTree a) } > > > Conveniently, `Gen` still has a unary type constructor of `a`. Further, if > users have implemented their `arbitrary` implementations in terms of the > QuickCheck combinators, their code won't have to change at all (I don't > think?). > The lower-level combinators would be updated to manipulate trees, with > functions like `joinRose` and `filterRose`. Let's next look at how `Gen` > would implement the monad type class: > > > instance Monad Gen where > return = MkGen . return . return > > gen >>= f = MkGen $ helper (unGen gen) (unGen . f) > -- sequence is from Data.Traversable > where helper m k = m >>= \y -> fmap joinRose $ sequence $ fmap > k y > > > The implementation of `return` is clear. `>>=` isn't too bad either: the > function provided to bind will return `Gen b`'s, and `joinRose` and > `sequence` > help us pull this `Generator (RoseTree b))` 'out', much like `join` does. > This > means our users can still write code like: > > > (arbitrary :: Gen [Int]) >>= elements > > > Which brings up a good point. The above code has an issue, `elements` is a > partial function with respect to the empty list. With the current > implementation, we'd use the `NonEmptyList` modifier, which much respect > this > predicate both during generation and shrinking. This change would allow all > predicates to be expressed simply with `suchThat`, which, since it acts on > both > values _and_ shrink trees, applies the predicate in both places. The > implementation of `suchThat` would have to unwrap `Gen`, and apply > `roseFilter` > to the `RoseTree` inside of `Generator`, using `fmap`. > > I have implemented the above description in my Clojure port of QuickCheck, > called simple-check [1], and it seems to be working quite nicely. Further, > I > suspect Erlang QuickCheck [3] is doing something similar, though their > implementation is not open source, I can't presume too much. > > Clearly this would be a big change, and my goal now is simply to start a > discussion: how does this sound? What's wrong, what's likely to break? > Feedback > and criticism welcome. > > Reid > > > [1] Scrap your boilerplate with class: extensible generic functions: > http://research.microsoft.com/pubs/67439/gmap3.pdf > > [2] https://github.com/reiddraper/simple-check > > [3] http://www.quviq.com/index.html > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Fri Nov 22 05:43:31 2013 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 22 Nov 2013 00:43:31 -0500 Subject: Maintaintership of HaLeX In-Reply-To: <528C965D.3000903@rochel.info> References: <528C965D.3000903@rochel.info> Message-ID: <59EE0CC2-5F1A-472E-8C7B-D9C4E3D1E8BA@cis.upenn.edu> Hello Jan, Thanks for offering to help with HaLeX. But, I think you've contacted the wrong list -- this list is for the maintenance of the core libraries that ship with Haskell. I believe you probably want to contact the Hackage trustees, who can transfer "ownership" of a package whose listed maintainer has become unresponsive. The Hackage trustees can be reached at admin at hackage.haskell.org. Thanks! Richard On Nov 20, 2013, at 6:00 AM, Jan Rochel wrote: > Hello. > > The current version (1.2) of HaLeX does not build on my machine > (ghc-7.6.3). The fix is very simple*, but the package maintainer has not > reacted on any of my emails during the last couple of months. I'd be > willing to take over maintainership, if people agree that this is the > best course of action. Otherwise I'd upload an additional fixed variant > of the package. > > Greetings, > Jan > > * add assumption (Eq st) on lines 80 and 104 of file > HaLeX_lib/Language/HaLex/Fa2RegExp.hs > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries From bos at serpentine.com Fri Nov 22 18:02:01 2013 From: bos at serpentine.com (Bryan O'Sullivan) Date: Fri, 22 Nov 2013 10:02:01 -0800 Subject: Proposal: free shrinking with QuickCheck In-Reply-To: References: Message-ID: On Thu, Nov 21, 2013 at 4:27 PM, Reid Draper wrote: > I originally sent this message to the QuickCheck mailing list, > but haven't heard anything in a while, and realized there are > only ten subscribers. Below is the original message, any feedback > appreciated. > I don't love this idea on first reading. The move to switch to generating a rose tree seems rather intrusive and like it could put a lot of complexity right in the paths of developers. That being said, I'd be interested in seeing the idea fleshed out to the point of determining whether my worry has any teeth - could the end-user writing of an Arbitrary instance remain unaffected in practice? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mainland at apeiron.net Fri Nov 22 18:05:36 2013 From: mainland at apeiron.net (Geoffrey Mainland) Date: Fri, 22 Nov 2013 10:05:36 -0800 Subject: Who needs and wants parallelism-friendly core libs? In-Reply-To: References: Message-ID: <20131122180536.GA59616@apeiron.net> I would be happy to share maintainership! Geoff On Thu, Nov 21, 2013 at 11:53:41AM -0500, Edward Kmett wrote: > Fair enough. I had missed that fact! In that case, we could bring vector > under the arm of the core libraries committee, or we could seek a more > direct maintainer.A > [Adding Geoffrey Mainland to the To: list] > Geoffrey, would you be willing to pick up maintainership?A > I mention it mostly because I know your recent SIMD work has been very > vector-centric, and you are the person most likely to affect it's course > in the near term. > If not, I could pick it up personally, or we could put it under the core > libraries committee. > -EdwardA > > On Thu, Nov 21, 2013 at 11:45 AM, Bryan O'Sullivan > wrote: > > On Thu, Nov 21, 2013 at 8:11 AM, Edward Kmett wrote: > > I'd like to hash this out a bit further. As this issue > affectsA vectorA primarily, it is outside of the scope of the core > library committee per se, and is largely up to Roman as the maintainer > ofA vector. > > Remember that Roman has fairly explicitly resigned as the maintainer of > vector for want of time, so someone else needs to take up the crusade > here. From bos at serpentine.com Fri Nov 22 18:05:37 2013 From: bos at serpentine.com (Bryan O'Sullivan) Date: Fri, 22 Nov 2013 10:05:37 -0800 Subject: Who needs and wants parallelism-friendly core libs? In-Reply-To: References: Message-ID: On Thu, Nov 21, 2013 at 4:31 PM, Edward Kmett wrote: > I'm happy to do that as well if you feel strongly, it just requires more > administrivia to coordinate, and the network graph on github shows the > activity across repositories anyways, so I tend to work by fork and pull > request, as I'm much more comfortable collapsing history on a repository > off to on side than I am on the official repo. *shrug* > Fair enough. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Fri Nov 22 18:56:18 2013 From: ekmett at gmail.com (Edward Kmett) Date: Fri, 22 Nov 2013 13:56:18 -0500 Subject: Who needs and wants parallelism-friendly core libs? In-Reply-To: <20131122180536.GA59616@apeiron.net> References: <20131122180536.GA59616@apeiron.net> Message-ID: How about this. It's yours. ;) If you need a hand from me or the core libraries committee feel free to ask. =) -Edward On Fri, Nov 22, 2013 at 1:05 PM, Geoffrey Mainland wrote: > I would be happy to share maintainership! > > Geoff > > On Thu, Nov 21, 2013 at 11:53:41AM -0500, Edward Kmett wrote: > > Fair enough. I had missed that fact! In that case, we could bring > vector > > under the arm of the core libraries committee, or we could seek a more > > direct maintainer.A > > [Adding Geoffrey Mainland to the To: list] > > Geoffrey, would you be willing to pick up maintainership?A > > I mention it mostly because I know your recent SIMD work has been very > > vector-centric, and you are the person most likely to affect it's > course > > in the near term. > > If not, I could pick it up personally, or we could put it under the > core > > libraries committee. > > -EdwardA > > > > On Thu, Nov 21, 2013 at 11:45 AM, Bryan O'Sullivan < > bos at serpentine.com> > > wrote: > > > > On Thu, Nov 21, 2013 at 8:11 AM, Edward Kmett > wrote: > > > > I'd like to hash this out a bit further. As this issue > > affectsA vectorA primarily, it is outside of the scope of the core > > library committee per se, and is largely up to Roman as the > maintainer > > ofA vector. > > > > Remember that Roman has fairly explicitly resigned as the > maintainer of > > vector for want of time, so someone else needs to take up the > crusade > > here. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From reiddraper at gmail.com Fri Nov 22 19:18:01 2013 From: reiddraper at gmail.com (Reid Draper) Date: Fri, 22 Nov 2013 13:18:01 -0600 Subject: Proposal: free shrinking with QuickCheck In-Reply-To: References: Message-ID: On Nov 22, 2013, at 12:02 PM, Bryan O'Sullivan wrote: > > On Thu, Nov 21, 2013 at 4:27 PM, Reid Draper wrote: > I originally sent this message to the QuickCheck mailing list, > but haven't heard anything in a while, and realized there are > only ten subscribers. Below is the original message, any feedback > appreciated. > > I don't love this idea on first reading. The move to switch to generating a rose tree seems rather intrusive and like it could put a lot of complexity right in the paths of developers. That being said, I'd be interested in seeing the idea fleshed out to the point of determining whether my worry has any teeth - could the end-user writing of an Arbitrary instance remain unaffected in practice? I'll take a stab at a minimal implementation. The goal would certainly be for users to be able to simply delete their `shrink` function. If they were previously using the default (shrink _ = []), they'd then get shrinking for free. For those looking for more motivation, take a look at how boilerplate shrink implementations end up being in practice. Further, care must be given to respect any implicit constraints during shrinking, that are respected during generation. For example, when generating with `choose 10 20`, you must never shrink to a value below 10. This would all be taken care of using the proposed method. critbit: https://github.com/bos/critbit/blob/master/tests/Properties/Common.hs#L32-L33 a boolean logic solver: https://github.com/reiddraper/haskell-logic/blob/master/logic.hs#L89-L106 pandoc, which doesn't have shrinking, conceivably it'd be quite tedious: https://github.com/jgm/pandoc/blob/master/tests/Tests/Arbitrary.hs -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at jspha.com Fri Nov 22 20:57:28 2013 From: me at jspha.com (Joseph Abrahamson) Date: Fri, 22 Nov 2013 15:57:28 -0500 Subject: Proposal: free shrinking with QuickCheck In-Reply-To: References: Message-ID: I really like this idea, but I think I?d personally love to see some examples of it in practice. 75% of my Arbitrary instances are ?traverse arbitrarily? and 95% of them keep Gen abstract, so I have a good feeling that it?d be possible to implement with relatively small amounts of user pain. The thing I wonder about is how often `arbitrary` declarations provide enough information for efficient, meaningful `shrink` declarations. If the two differ it may be more necessary to break into `Gen` to provide the right kind of behavior?which would be increasingly complex. I?d love to see some examples of complex generators from simple-check implemented in this style. As an ugly example I frequently run into in my own code, it?s often hard to write a good arbitrary instance for UTCTime?it?s very domain specific what defines a good arbitrary time. Would such kinds of complex generator code also lead to a nice shrink function? Or would it require something more complex? --? Joseph Abrahamson Sent with Airmail On November 22, 2013 at 2:18:13 PM, Reid Draper (reiddraper at gmail.com) wrote: On Nov 22, 2013, at 12:02 PM, Bryan O'Sullivan wrote: On Thu, Nov 21, 2013 at 4:27 PM, Reid Draper wrote: I originally sent this message to the QuickCheck mailing list, but haven't heard anything in a while, and realized there are only ten subscribers. Below is the original message, any feedback appreciated. I don't love this idea on first reading. The move to switch to generating a rose tree seems rather intrusive and like it could put a lot of complexity right in the paths of developers. That being said, I'd be interested in seeing the idea fleshed out to the point of determining whether my worry has any teeth - could the end-user writing of an Arbitrary instance remain unaffected in practice? I'll take a stab at a minimal implementation. The goal would certainly be for users to be able to simply delete their `shrink` function. If they were previously using the default (shrink _ = []), they'd then get shrinking for free. For those looking for more motivation, take a look at how boilerplate shrink implementations end up being in practice. Further, care must be given to respect any implicit constraints during shrinking, that are respected during generation. For example, when generating with `choose 10 20`, you must never shrink to a value below 10. This would all be taken care of using the proposed method. critbit:?https://github.com/bos/critbit/blob/master/tests/Properties/Common.hs#L32-L33 a boolean logic solver:?https://github.com/reiddraper/haskell-logic/blob/master/logic.hs#L89-L106 pandoc, which doesn't have shrinking, conceivably it'd be quite tedious:?https://github.com/jgm/pandoc/blob/master/tests/Tests/Arbitrary.hs _______________________________________________ Libraries mailing list Libraries at haskell.org http://www.haskell.org/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From edsoares110 at gmail.com Sun Nov 24 03:42:10 2013 From: edsoares110 at gmail.com (Ed Soares) Date: Sun, 24 Nov 2013 01:42:10 -0200 Subject: Lista de emails como fazer mala direta lista de empresas Message-ID: <13850020331e9eeb35d87b0ace454b76f626c7f060@gmail.com> Lista de emails como fazer mala direta lista de empresas listagem de empresas al?m de lista de emails, email em massa envio de email: http://www.maladiretaemails.com todos devem saber que como fazer uma mala direta, ? geralmente um muito legal para a maioria das pessoas. trabalhe com mala direta emails de empresas tais como lista de emails, envio de email o que e mailing, ? realmente o objetivo de nosso Site. Voc? est? procurando list mail, email em massa juntamente com email cadastro: http://www.maladiretaemails.com ? muito legal emails empresas que cont?m listas email, trabalhe com mala direta listagem de empresas. ? otimo email de empresas e como email marketing. list mail programa para enviar e mail, endereco de email. no momento listas de emails adicionalmente Enviar email, lista de mail ? realmente otimo. o objetivo de nosso website: email em massa, Enviar email, e tamb?m emails empresas. N?s fornecemos listas de emails emails empresas, list mail. From wren at freegeek.org Mon Nov 25 08:50:07 2013 From: wren at freegeek.org (wren at freegeek.org) Date: Mon, 25 Nov 2013 03:50:07 -0500 Subject: System.Posix.IO.ByteString fdRead and fdWrite. In-Reply-To: References: Message-ID: <95d1d62b082056d2a3b3c6f0cd974d7c@freegeek.org> On 11/20/13 6:03 PM, Ashley Yakeley wrote: > In unix-2.7.0.0, fdRead and fdWrite in System.Posix.IO.ByteString use > String instead of ByteString. This is wrong, isn't it? The point of > the > .ByteString modules is to do IO in ByteString. The functions you're looking for are in unix-bytestring[1]. They also have precedent on the System.Posix.IO.ByteString module name, but there was a bit of a mixup back when the ByteString-based filename stuff was introduced in unix. The unix-bytestring package was always intended to be rolled into unix. When I proposed incorporating it back in the day, the original version mirrored the System.Posix.IO API and the proposal was voted down because noone liked the System.Posix.IO API! I've since redone the API to better match the POSIX standards, and have gotten positive feedback on it. So perhaps it's time to revive the proposal for inclusion. [1] -- Live well, ~wren From reiddraper at gmail.com Mon Nov 25 20:44:44 2013 From: reiddraper at gmail.com (Reid Draper) Date: Mon, 25 Nov 2013 14:44:44 -0600 Subject: Proposal: free shrinking with QuickCheck In-Reply-To: References: Message-ID: On Nov 22, 2013, at 2:57 PM, Joseph Abrahamson wrote: > I really like this idea, but I think I?d personally love to see some examples of it in practice. 75% of my Arbitrary instances are ?traverse arbitrarily? and 95% of them keep Gen abstract, so I have a good feeling that it?d be possible to implement with relatively small amounts of user pain. That's been my experience as well, though I haven't even had the 5% where I've had to break the Gen abstraction. > > The thing I wonder about is how often `arbitrary` declarations provide enough information for efficient, meaningful `shrink` declarations. If the two differ it may be more necessary to break into `Gen` to provide the right kind of behavior?which would be increasingly complex. My experience with both Erlang QuickCheck and simple-check (Clojure) is that it _is_ enough information. In the rare cases it's not, you can always still implement your own logic for shrinking by breaking the Gen abstraction (manipulating the RoseTree yourself). > > I?d love to see some examples of complex generators from simple-check implemented in this style. As an ugly example I frequently run into in my own code, it?s often hard to write a good arbitrary instance for UTCTime?it?s very domain specific what defines a good arbitrary time. Would such kinds of complex generator code also lead to a nice shrink function? Or would it require something more complex? I think a powerful example is an 'any' generator I have in simple-check, which will generate arbitrary Clojure values [1]. It's constructed in exactly the same way as you'd do it with today's QuickCheck, but it also shrinks as well as a hand-written shrink algorithm. (I've found edge-cases in Clojure's reader/writer this way). [1] https://github.com/reiddraper/simple-check/blob/v0.5.3/src/simple_check/generators.clj#L525-L553 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bos at serpentine.com Tue Nov 26 00:09:07 2013 From: bos at serpentine.com (Bryan O'Sullivan) Date: Mon, 25 Nov 2013 16:09:07 -0800 Subject: Proposal: free shrinking with QuickCheck In-Reply-To: References: Message-ID: On Mon, Nov 25, 2013 at 12:44 PM, Reid Draper wrote: > My experience with both Erlang QuickCheck and simple-check (Clojure) is > that it _is_ enough information. In the rare cases it's not, you can always > still implement your own logic for shrinking by breaking the Gen > abstraction (manipulating the RoseTree yourself). > It seems we're cautiously optimistic that this could work. I think the next step is up to you. If I were in your shoes, here's what I'd do: patch up QuickCheck to make this change, and then for some fairly large handful of widely-used packages on Hackage that have test suites, see how many of them can build more or less unscathed, maybe with the shrink method still present in the typeclass so that packages that define it don't have spurious build failures - and then see how many test suites continue to work okay. In other words, I think this is worth pursuing, and that the best way to make progress on it is to try it and see how well it goes. That way, you can come back armed with both a diff and evidence that it's good. -------------- next part -------------- An HTML attachment was scrubbed... URL: From reiddraper at gmail.com Tue Nov 26 02:06:32 2013 From: reiddraper at gmail.com (Reid Draper) Date: Mon, 25 Nov 2013 20:06:32 -0600 Subject: Proposal: free shrinking with QuickCheck In-Reply-To: References: Message-ID: On Nov 25, 2013, at 6:09 PM, Bryan O'Sullivan wrote: > > On Mon, Nov 25, 2013 at 12:44 PM, Reid Draper wrote: > My experience with both Erlang QuickCheck and simple-check (Clojure) is that it _is_ enough information. In the rare cases it's not, you can always still implement your own logic for shrinking by breaking the Gen abstraction (manipulating the RoseTree yourself). > > It seems we're cautiously optimistic that this could work. I think the next step is up to you. > > If I were in your shoes, here's what I'd do: patch up QuickCheck to make this change, and then for some fairly large handful of widely-used packages on Hackage that have test suites, see how many of them can build more or less unscathed, maybe with the shrink method still present in the typeclass so that packages that define it don't have spurious build failures - and then see how many test suites continue to work okay. > > In other words, I think this is worth pursuing, and that the best way to make progress on it is to try it and see how well it goes. That way, you can come back armed with both a diff and evidence that it's good. Good advice, thanks. Reid -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Tue Nov 26 04:19:18 2013 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Mon, 25 Nov 2013 20:19:18 -0800 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: References: <1384961876.7607.186.camel@dunky.localdomain> Message-ID: My view of the conversation so far: 1) Aeson option 3 or 4 is desirable - we all want aeson, we don't want blaze-builder 2) dlist has generated a fair bit of discussion, but no clear agreement. 3) no one has weighed in on scientific We need to come to rough consensus on these issues soon if we are to get to aeson in this round. My opinion, with my "HP Release Manager" hat on: I'd like to see a version of aeson-0.7 that didn't use dlist (just, ick, duplicated what it used in it's innards), and either had the Scientific removed, or as part of aeson itself (rather than as a separate package). I recognize the sub-standardness of this solution, though it is forward compatible with future evolutions (such as exposing dlist, and/or scientific). - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.dead.shall.rise at gmail.com Tue Nov 26 04:46:47 2013 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Tue, 26 Nov 2013 05:46:47 +0100 Subject: 2013.4.0.0 proposal - getting to alpha In-Reply-To: References: Message-ID: Hi Mark, On Sun, Nov 17, 2013 at 8:55 PM, Mark Lentczner wrote: > Here is the current status of the 2013.4.0.0 proposal. > > [...] > > Cabal: > Cabal: 1.16.0 ? 1.18.1.2 consensus seems to be that this will be > okay Will it be fine to include both versions of Cabal with the installer (to avoid building GHC myself)? The installer can run `ghc-pkg hide Cabal-1.16` as the final step, so the user will never even see the extra copy of Cabal. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From ivan.miljenovic at gmail.com Tue Nov 26 05:02:07 2013 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Tue, 26 Nov 2013 16:02:07 +1100 Subject: 2013.4.0.0 proposal - getting to alpha In-Reply-To: References: Message-ID: On 26 November 2013 15:46, Mikhail Glushenkov wrote: > Hi Mark, > > On Sun, Nov 17, 2013 at 8:55 PM, Mark Lentczner > wrote: >> Here is the current status of the 2013.4.0.0 proposal. >> >> [...] >> >> Cabal: >> Cabal: 1.16.0 ? 1.18.1.2 consensus seems to be that this will be >> okay > > Will it be fine to include both versions of Cabal with the installer > (to avoid building GHC myself)? The installer can run `ghc-pkg hide > Cabal-1.16` as the final step, so the user will never even see the > extra copy of Cabal. Is this necessary? For me at least, "ghc-pkg list" still shows non-exposed packages (but shades them blue in the output list; I've also had them appear in braces before IIRC). Using ghci or just ghc with Cabal modules will default to the highest version unless specified otherwise. -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From ivan.miljenovic at gmail.com Tue Nov 26 06:28:36 2013 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Tue, 26 Nov 2013 17:28:36 +1100 Subject: 2013.4.0.0 proposal - getting to alpha In-Reply-To: References: Message-ID: Hurt, no; but it will make it inconsistent across platforms (as Linux distros typically just have meta-packages for the Platform, rather than an installer that can do this). On 26 November 2013 17:16, Mikhail Glushenkov wrote: > Hi, > > On Tue, Nov 26, 2013 at 6:02 AM, Ivan Lazar Miljenovic > wrote: >> On 26 November 2013 15:46, Mikhail Glushenkov >> wrote: >>> [...] >>> The installer can run `ghc-pkg hide >>> Cabal-1.16` as the final step, so the user will never even see the >>> extra copy of Cabal. >> >> Is this necessary? > > Well, hiding Cabal-1.16 certainly can't hurt, can it? > > -- > () ascii ribbon campaign - against html e-mail > /\ www.asciiribbon.org - against proprietary attachments -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From the.dead.shall.rise at gmail.com Tue Nov 26 07:04:21 2013 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Tue, 26 Nov 2013 08:04:21 +0100 Subject: 2013.4.0.0 proposal - getting to alpha In-Reply-To: References: Message-ID: Hi, On Tue, Nov 26, 2013 at 7:28 AM, Ivan Lazar Miljenovic wrote: > Hurt, no; but it will make it inconsistent across platforms (as Linux > distros typically just have meta-packages for the Platform, rather > than an installer that can do this). > You mean that Linux distros will have both 1.18 and 1.16, but 1.16 won't be hidden? Will this affect anything if 1.18 will be always chosen by default anyway? -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From ivan.miljenovic at gmail.com Tue Nov 26 08:08:27 2013 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Tue, 26 Nov 2013 19:08:27 +1100 Subject: 2013.4.0.0 proposal - getting to alpha In-Reply-To: References: Message-ID: On 26 November 2013 18:04, Mikhail Glushenkov wrote: > Hi, > > On Tue, Nov 26, 2013 at 7:28 AM, Ivan Lazar Miljenovic > wrote: >> Hurt, no; but it will make it inconsistent across platforms (as Linux >> distros typically just have meta-packages for the Platform, rather >> than an installer that can do this). >> > > You mean that Linux distros will have both 1.18 and 1.16, but 1.16 > won't be hidden? Will this affect anything if 1.18 will be always > chosen by default anyway? No, but if the binary installers auto-hide 1.16, then there will be a difference between the various platforms. -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From carter.schonwald at gmail.com Tue Nov 26 08:18:15 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 26 Nov 2013 03:18:15 -0500 Subject: 2013.4.0.0 proposal - getting to alpha In-Reply-To: References: Message-ID: or just build ghc with the 1.18 cabal and keep it all the same :) On Tue, Nov 26, 2013 at 3:08 AM, Ivan Lazar Miljenovic < ivan.miljenovic at gmail.com> wrote: > On 26 November 2013 18:04, Mikhail Glushenkov > wrote: > > Hi, > > > > On Tue, Nov 26, 2013 at 7:28 AM, Ivan Lazar Miljenovic > > wrote: > >> Hurt, no; but it will make it inconsistent across platforms (as Linux > >> distros typically just have meta-packages for the Platform, rather > >> than an installer that can do this). > >> > > > > You mean that Linux distros will have both 1.18 and 1.16, but 1.16 > > won't be hidden? Will this affect anything if 1.18 will be always > > chosen by default anyway? > > No, but if the binary installers auto-hide 1.16, then there will be a > difference between the various platforms. > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic at gmail.com > http://IvanMiljenovic.wordpress.com > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.dead.shall.rise at gmail.com Tue Nov 26 09:47:18 2013 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Tue, 26 Nov 2013 10:47:18 +0100 Subject: 2013.4.0.0 proposal - getting to alpha In-Reply-To: References: Message-ID: On Tue, Nov 26, 2013 at 9:18 AM, Carter Schonwald wrote: > or just build ghc with the 1.18 cabal and keep it all the same :) That's what I'd like to avoid. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From greg at gregorycollins.net Tue Nov 26 12:46:35 2013 From: greg at gregorycollins.net (Gregory Collins) Date: Tue, 26 Nov 2013 13:46:35 +0100 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: References: <1384961876.7607.186.camel@dunky.localdomain> Message-ID: Is there a way to include packages as second-class in the platform? I.e. "this package isn't 'blessed' but for now it's required by a package we really do want." Then we could work later to either bring the dependencies into the platform or rework the platform packages to exclude the non-platform dependency. On Tue, Nov 26, 2013 at 5:19 AM, Mark Lentczner wrote: > My view of the conversation so far: > > 1) Aeson option 3 or 4 is desirable - we all want aeson, we don't want > blaze-builder > 2) dlist has generated a fair bit of discussion, but no clear agreement. > 3) no one has weighed in on scientific > > We need to come to rough consensus on these issues soon if we are to get > to aeson in this round. > > My opinion, with my "HP Release Manager" hat on: I'd like to see a version > of aeson-0.7 that didn't use dlist (just, ick, duplicated what it used in > it's innards), and either had the Scientific removed, or as part of aeson > itself (rather than as a separate package). I recognize the > sub-standardness of this solution, though it is forward compatible with > future evolutions (such as exposing dlist, and/or scientific). > > - Mark > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -- Gregory Collins -------------- next part -------------- An HTML attachment was scrubbed... URL: From dons00 at gmail.com Tue Nov 26 13:30:08 2013 From: dons00 at gmail.com (Don Stewart) Date: Tue, 26 Nov 2013 13:30:08 +0000 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: <1384766504.2488.10.camel@kirk> References: <1384766504.2488.10.camel@kirk> Message-ID: Indeed, avoiding expensive instances was part of the design On Nov 18, 2013 5:21 PM, "Joachim Breitner" wrote: > Hi, > > Am Montag, den 18.11.2013, 10:04 +0200 schrieb Sean Leather: > > * Maintenance and development taken over by Sean Leather > > * Migrate repository from http://code.haskell.org/~dons/code/dlist/ to > > https://github.com/spl/dlist > > * Add `Eq`, `Ord`, `Read`, `Show`, `Alternative`, `Foldable`, > `Traversable` > > instances > > Given that the point of dlist is to speed up code where lists are > insufficient, would it make sense to only provide those instances that > can be implemented without converting to and from lists? > > If there are instances that cannot be implemented idiomatically with > dlists, maybe they should be left out, to signal the user that he will > not get the benefits of DLists for these. > > In particular, it seems that the Show instance could be improved. > Currently it says > showsPrec p dl = showParen (p > 10) $ > showString "fromList " . shows (toList dl) > i.e. goes via a list. But this is constructing a ShowS (which is String > -> String) value, i.e. another difference list. Shouldn?t it be possible > to stay in the world of difference lists when implementing this? > > (Or maybe I?m overly worried, and I admit that I did not run benchmarks > so far.) > > Greetings, > Joachim > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C > Debian Developer: nomeata at debian.org > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Tue Nov 26 16:01:34 2013 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Tue, 26 Nov 2013 08:01:34 -0800 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: References: <1384961876.7607.186.camel@dunky.localdomain> Message-ID: On Tue, Nov 26, 2013 at 4:46 AM, Gregory Collins wrote: > Is there a way to include packages as second-class in the platform? > We quasi-did that with primitives. But as I recall, the discussion at the time acknowledged the ineffectiveness of the approach: The point of the platform is that if you compile against the platform, it should be stable - and there is really no effective way to keep people from compiling against them, or even warn them: We could hide them in the package database, but cabal will "unearth" them, without warning, if your project requires it. I suppose this points at an interesting possible cabal enhancement: If it chooses a package that is hidden in the db, it warns you at configure time, even though at build time it is going to use it. - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Tue Nov 26 16:07:30 2013 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Tue, 26 Nov 2013 08:07:30 -0800 Subject: 2013.4.0.0 proposal - getting to alpha In-Reply-To: References: Message-ID: I don't think there is an issue with building GHC: If you build GHC from source for packaging, it will build and use the version of the Cabal package that it is shipped with. This will put Cabal-1.16 in the package database. If you then build all the packages in the platform, that will build Cabal 1.18 and cabal-install 1.18 and add them to the package database as well. This will then exactly match the template of the platform, I think. ? - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhymoid at gmail.com Tue Nov 26 16:50:05 2013 From: rhymoid at gmail.com (Stijn van Drongelen) Date: Tue, 26 Nov 2013 17:50:05 +0100 Subject: 2013.4.0.0 proposal - getting to alpha In-Reply-To: References: Message-ID: I'm probably missing something here, but is `containers` not part of HP? On Sun, Nov 17, 2013 at 8:55 PM, Mark Lentczner wrote: > Here is the current status of the 2013.4.0.0 proposal. > > *Outstanding Issues* > We have a few decisions outstanding, and I'd like to have these decided by > Nov. 23 (one week). > > - fgl - waiting to hear if Ivan will have new version ready in time. > - aeson / dlist - there are serveral options -- I'll start a separate > thread on this topic. > - alex / happy - I'd like to hear an "okay" from the maintainers on > the major version bump > > > *Current Proposed Versions* > *GHC 7.6.3* -- same as last time (erroneously listed as a version bump > last time) > > *Packages with no changes:* > fgl, haskell-src, html, HUnit, > mtl, parsec, QuickCheck, random, > regex-base, regex-compat, regex-posix, > split, stm, text, transformers, > xhtml, zlib > > *Packages held back:* > cgi: 3001.1.7.5 (3001.1.8.4* requires MonadCatchIO-mtl)* > > *Packages with minor version bumps:* > HTTP: 4000.2.8 ? 4000.2.9 > network: 2.4.1.2 ? 2.4.2.0 > parallel: 3.2.0.3 ? 3.2.0.4 > syb: 0.4.0 ? 0.4.1 > unordered-containers: 0.2.3.0 ? 0.2.3.3 > vector: 0.10.0.1 ? 0.10.9.1? > primitive: 0.5.0.1 ? 0.5.1.0? > > *Packages with major version bumps:* > case-insensitive: 1.0.0.1 ? 1.1.0.1 > hashable: 1.1.2.5 ? 1.2.1.0 > > GLUT: 2.4.0.0 ? 2.5.0.1 > GLURaw: 1.3.0.0 ? 1.4.0.0 > OpenGL: 2.8.0.0 ? 2.9.1.0 > OpenGLRaw: 1.3.0.0 ? 1.4.0.0 > > alex: 3.0.5 ? 3.1.0 *pending okay* > happy: 1.18.10 ? 1.19.0 *pending okay* > > *Cabal:* > Cabal: 1.16.0 ? 1.18.1.2 *consensus seems to be that this will be > okay* > cabal-install: 1.16.0.2 ? 1.18.0.2 > > > *Platform Packagers:* > This is likely to be the last HP source release that contains all the ad > hoc scripts for packaging. I canvased the group last time and as I recall, > everyone said they just used the .cabal file - and no one used the scripts. > I plan to replace them with a new tool built for the needs of the release, > and ditch this old set of scripts. If you need 'em, speak now, or forever > hold your peace! > > ? Mark > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Tue Nov 26 17:47:47 2013 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Tue, 26 Nov 2013 09:47:47 -0800 Subject: 2013.4.0.0 proposal - getting to alpha In-Reply-To: References: Message-ID: On Tue, Nov 26, 2013 at 8:50 AM, Stijn van Drongelen wrote: > I'm probably missing something here, but is `containers` not part of HP? > Yes - it is, but it is part of the set of packages that come with GHC, hence I didn't list it by itself. Those packages are: array, base, bytestring, Cabal, contianers, deepseq, director, filepath, haskell2010, haskell98, hpc, old-locale, old-time, pretty, process, template-haskell, time, unix, & Win32. - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Tue Nov 26 21:01:45 2013 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Tue, 26 Nov 2013 22:01:45 +0100 Subject: 2013.4.0.0 proposal - getting to alpha In-Reply-To: (Mark Lentczner's message of "Tue, 26 Nov 2013 09:47:47 -0800") References: Message-ID: <87vbzeubba.fsf@gnu.org> On 2013-11-26 at 18:47:47 +0100, Mark Lentczner wrote: >> I'm probably missing something here, but is `containers` not part of HP? > Yes - it is, but it is part of the set of packages that come with GHC, > hence I didn't list it by itself. > Those packages are: array, base, bytestring, Cabal, contianers, deepseq, > director, filepath, haskell2010, haskell98, hpc, old-locale, old-time, > pretty, process, template-haskell, time, unix, & Win32. btw, here's also a table representation of which GHC version (from 7.0.1 up) shipped with which package versions: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Libraries/VersionHistory From gale at sefer.org Wed Nov 27 09:26:26 2013 From: gale at sefer.org (Yitzchak Gale) Date: Wed, 27 Nov 2013 11:26:26 +0200 Subject: 2013.4.0.0 proposal - getting to alpha In-Reply-To: References: Message-ID: To remind people of an issue I have brought up in the past: Could this version of HP please also include an installer for Linux that does not include the OpenGL-related packages? This is needed to be able to install HP on a headless Linux server. Otherwise, the only way to install HP is to install a boatload of X server dependencies, and possibly even the X server itself, defeating the whole purpose of having a headless server. Thanks, Yitz On Sun, Nov 17, 2013 at 9:55 PM, Mark Lentczner wrote: > Here is the current status of the 2013.4.0.0 proposal. > > Outstanding Issues > We have a few decisions outstanding, and I'd like to have these decided by > Nov. 23 (one week). > > fgl - waiting to hear if Ivan will have new version ready in time. > aeson / dlist - there are serveral options -- I'll start a separate thread > on this topic. > alex / happy - I'd like to hear an "okay" from the maintainers on the major > version bump > > > Current Proposed Versions > GHC 7.6.3 -- same as last time (erroneously listed as a version bump last > time) > > Packages with no changes: > fgl, haskell-src, html, HUnit, > mtl, parsec, QuickCheck, random, > regex-base, regex-compat, regex-posix, > split, stm, text, transformers, > xhtml, zlib > > Packages held back: > cgi: 3001.1.7.5 (3001.1.8.4 requires MonadCatchIO-mtl) > > Packages with minor version bumps: > HTTP: 4000.2.8 ? 4000.2.9 > network: 2.4.1.2 ? 2.4.2.0 > parallel: 3.2.0.3 ? 3.2.0.4 > syb: 0.4.0 ? 0.4.1 > unordered-containers: 0.2.3.0 ? 0.2.3.3 > vector: 0.10.0.1 ? 0.10.9.1? > primitive: 0.5.0.1 ? 0.5.1.0? > > Packages with major version bumps: > case-insensitive: 1.0.0.1 ? 1.1.0.1 > hashable: 1.1.2.5 ? 1.2.1.0 > > GLUT: 2.4.0.0 ? 2.5.0.1 > GLURaw: 1.3.0.0 ? 1.4.0.0 > OpenGL: 2.8.0.0 ? 2.9.1.0 > OpenGLRaw: 1.3.0.0 ? 1.4.0.0 > > alex: 3.0.5 ? 3.1.0 pending okay > happy: 1.18.10 ? 1.19.0 pending okay > > Cabal: > Cabal: 1.16.0 ? 1.18.1.2 consensus seems to be that this will be > okay > cabal-install: 1.16.0.2 ? 1.18.0.2 > > > Platform Packagers: > This is likely to be the last HP source release that contains all the ad hoc > scripts for packaging. I canvased the group last time and as I recall, > everyone said they just used the .cabal file - and no one used the scripts. > I plan to replace them with a new tool built for the needs of the release, > and ditch this old set of scripts. If you need 'em, speak now, or forever > hold your peace! > > ? Mark > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From gale at sefer.org Wed Nov 27 09:29:03 2013 From: gale at sefer.org (Yitzchak Gale) Date: Wed, 27 Nov 2013 11:29:03 +0200 Subject: 2013.4.0.0 proposal - getting to alpha In-Reply-To: References: Message-ID: Sorry, by "installer" I meant a source package. Or just a make target that excludes those. So I am presuming (hoping?) that this would not be much extra work. Thanks, Yitz On Wed, Nov 27, 2013 at 11:26 AM, Yitzchak Gale wrote: > To remind people of an issue I have brought up in the past: > > Could this version of HP please also include an installer for Linux > that does not > include the OpenGL-related packages? This is needed to be able to install > HP on a headless Linux server. Otherwise, the only way to install HP > is to install a boatload of X server dependencies, and possibly even the > X server itself, defeating the whole purpose of having a headless server. > > Thanks, > Yitz > > > On Sun, Nov 17, 2013 at 9:55 PM, Mark Lentczner > wrote: >> Here is the current status of the 2013.4.0.0 proposal. >> >> Outstanding Issues >> We have a few decisions outstanding, and I'd like to have these decided by >> Nov. 23 (one week). >> >> fgl - waiting to hear if Ivan will have new version ready in time. >> aeson / dlist - there are serveral options -- I'll start a separate thread >> on this topic. >> alex / happy - I'd like to hear an "okay" from the maintainers on the major >> version bump >> >> >> Current Proposed Versions >> GHC 7.6.3 -- same as last time (erroneously listed as a version bump last >> time) >> >> Packages with no changes: >> fgl, haskell-src, html, HUnit, >> mtl, parsec, QuickCheck, random, >> regex-base, regex-compat, regex-posix, >> split, stm, text, transformers, >> xhtml, zlib >> >> Packages held back: >> cgi: 3001.1.7.5 (3001.1.8.4 requires MonadCatchIO-mtl) >> >> Packages with minor version bumps: >> HTTP: 4000.2.8 ? 4000.2.9 >> network: 2.4.1.2 ? 2.4.2.0 >> parallel: 3.2.0.3 ? 3.2.0.4 >> syb: 0.4.0 ? 0.4.1 >> unordered-containers: 0.2.3.0 ? 0.2.3.3 >> vector: 0.10.0.1 ? 0.10.9.1? >> primitive: 0.5.0.1 ? 0.5.1.0? >> >> Packages with major version bumps: >> case-insensitive: 1.0.0.1 ? 1.1.0.1 >> hashable: 1.1.2.5 ? 1.2.1.0 >> >> GLUT: 2.4.0.0 ? 2.5.0.1 >> GLURaw: 1.3.0.0 ? 1.4.0.0 >> OpenGL: 2.8.0.0 ? 2.9.1.0 >> OpenGLRaw: 1.3.0.0 ? 1.4.0.0 >> >> alex: 3.0.5 ? 3.1.0 pending okay >> happy: 1.18.10 ? 1.19.0 pending okay >> >> Cabal: >> Cabal: 1.16.0 ? 1.18.1.2 consensus seems to be that this will be >> okay >> cabal-install: 1.16.0.2 ? 1.18.0.2 >> >> >> Platform Packagers: >> This is likely to be the last HP source release that contains all the ad hoc >> scripts for packaging. I canvased the group last time and as I recall, >> everyone said they just used the .cabal file - and no one used the scripts. >> I plan to replace them with a new tool built for the needs of the release, >> and ditch this old set of scripts. If you need 'em, speak now, or forever >> hold your peace! >> >> ? Mark >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> From bos at serpentine.com Wed Nov 27 17:27:12 2013 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed, 27 Nov 2013 09:27:12 -0800 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: References: <1384961876.7607.186.camel@dunky.localdomain> Message-ID: On Mon, Nov 25, 2013 at 8:19 PM, Mark Lentczner wrote: > 1) Aeson option 3 or 4 is desirable - we all want aeson, we don't want > blaze-builder > 2) dlist has generated a fair bit of discussion, but no clear agreement. > 3) no one has weighed in on scientific > I spent a bit of time digging into aeson's use of dlist this morning (I didn't add it myself, hence the need to dig), and it actually uses almost the entire API. I do not plan to duplicate dlist into aeson, so the remaining options are to bring dlist into the platform (which is fine by me), or omit aeson. The dlist package is somewhat widely used, and it's very stable, so I am unfussed about its inclusion. Regarding scientific, it solves a real problem with correctness in previous versions of aeson. It is admittedly both new and nichey, but I would be fine to see it go into the platform for the same reason we were okay including the primitive package. It is depended upon by both the latest or HEAD versions of attoparsec and aeson, so the option to fold its code into aeson doesn't really exist. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Wed Nov 27 18:05:33 2013 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 27 Nov 2013 13:05:33 -0500 Subject: role signatures in libraries Message-ID: <871C45BC-6380-4809-A812-C7E3B82AA69E@cis.upenn.edu> Hi libraries, It seems that the syntax and semantics of role annotations has settled, and so it's time to add role annotations to various libraries. Here are the key ideas: tl;dr: Add nominal role annotations for abstract datatypes whose data has an invariant based on a class instance. Set and Map are top candidates. - We have three notions of equality: nominal, representational, and phantom. - Type equality as we know it is called *nominal*. - A newtype is considered *representationally* equal to its representation type. * Thus, if we have `newtype Age = MkAge Int`, `Age` and `Int` are representationally equal. - Any two types are "phantomly" equal. * See below for an illustrative example of why this notion is useful. - Every type parameter of every datatype and class is assigned a role. A parameter's role says what notion of equality must hold to show that two instantiations of the datatype are representationally equal. * Say we have `Bar a` where a's role is nominal. That means that `Bar Age` is *not* representationally equal to `Bar Int`. * Say we have `Foo a` where a's role is representational. That means that `Foo Age` is representationally equal to `Foo Int`. * Say we have `Quux a` where a's role is phantom. That means that `Quux Int` is representationally equal to `Quux Bool`. - Datatype roles are inferred to be the most permissive possible. * `data Bar a = MkBar (F a)` where `F` is a type family: a's role will be inferred to be nominal. * `data Foo a = MkFoo a`: a's role will be inferred to be representational. * `data Quux a = MkQuux String`: a's role will be inferred to be phantom. - Class roles are inferred to be nominal. * This choice follows from the idea that the dictionaries for `Ord Int` and `Ord Age` should not be assumed to be the same. - A role annotation can be used to change a parameter's role. The syntax is a top-level declaration `type role `. You need the extension RoleAnnotations to use these. Role names are spelled out (nominal, representational, phantom) and are in lower-case. * If we wanted, say, Quux's parameter's role to be representational, we could say `type role Quux representational`. - Role annotations must be in the same module as a type is defined in. - Roles can be left out by inserting `_`. This causes the role to be inferred. - Role annotations cannot be used to undercut type safety. They are checked to make sure they meet this requirement. - The new function `coerce` (in GHC.Exts) allows for 0-cost conversion between representationally equal types. * This means that converting [Quux Bool] to [Quux Int] is now free. This is why phantom equality is interesting. - You should consider adding a role annotation on any type that has an invariant based on class instances. * For example, the information stored in a Set is ordered according to the data's Ord instance. So, there should probably be an annotation `type role Set nominal`. * As a further example, the data stored in a Map cares about the Ord instance of its first parameter but not its second. So, we would probably want `type role Map nominal representational`. Note that the new roles stuff does *not* allow programmers to do more bad things than they could previously. A sufficiently clever use of GeneralizedNewtypeDeriving could invalidate any instance-based invariants you wished to impose. However, we now have the power to stop these leaks of abstraction. We also have, in `coerce`, an easier way to take advantage of any remaining holes, making it even more important to close the gaps. The user manual is updated with respect to all the roles stuff -- you may want to see there for more info. Please let me know if you have any questions about this! Richard From lemming at henning-thielemann.de Wed Nov 27 18:18:56 2013 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 27 Nov 2013 19:18:56 +0100 (CET) Subject: role signatures in libraries In-Reply-To: <871C45BC-6380-4809-A812-C7E3B82AA69E@cis.upenn.edu> References: <871C45BC-6380-4809-A812-C7E3B82AA69E@cis.upenn.edu> Message-ID: On Wed, 27 Nov 2013, Richard Eisenberg wrote: > It seems that the syntax and semantics of role annotations has settled, > and so it's time to add role annotations to various libraries. This topic is completely new to me. Where can I read what it is about, what is its motivation? From spam at scientician.net Wed Nov 27 18:27:57 2013 From: spam at scientician.net (Bardur Arantsson) Date: Wed, 27 Nov 2013 19:27:57 +0100 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: References: <1384961876.7607.186.camel@dunky.localdomain> Message-ID: On 2013-11-27 18:27, Bryan O'Sullivan wrote: > On Mon, Nov 25, 2013 at 8:19 PM, Mark Lentczner wrote: > >> 1) Aeson option 3 or 4 is desirable - we all want aeson, we don't want >> blaze-builder >> 2) dlist has generated a fair bit of discussion, but no clear agreement. >> 3) no one has weighed in on scientific >> > > I spent a bit of time digging into aeson's use of dlist this morning (I > didn't add it myself, hence the need to dig), and it actually uses almost > the entire API. I do not plan to duplicate dlist into aeson, so the > remaining options are to bring dlist into the platform (which is fine by > me), or omit aeson. The dlist package is somewhat widely used, and it's > very stable, so I am unfussed about its inclusion. > I think the objection people have is that there are (were?) some last-minute changes to dlist as indicated here: http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/20698 I think many of the objections were raised before the details of the changes were known, so meh. +0, I guess. (I was one of the original objectors based on the requirement for API stability before inclusion in the HP.) > Regarding scientific, it solves a real problem with correctness in previous > versions of aeson. It is admittedly both new and nichey, but I would be > fine to see it go into the platform for the same reason we were okay > including the primitive package. It is depended upon by both the latest or > HEAD versions of attoparsec and aeson, so the option to fold its code into > aeson doesn't really exist. +1 From carter.schonwald at gmail.com Wed Nov 27 19:14:29 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 27 Nov 2013 14:14:29 -0500 Subject: role signatures in libraries In-Reply-To: References: <871C45BC-6380-4809-A812-C7E3B82AA69E@cis.upenn.edu> Message-ID: Henning, Roles were cooked up to address the fact that currently, its possible to derive unsafeCoerce via the use of Generalized Newtype Deriving. Roles address that issue and close that type safety hole. Richard has a paper or so on it, and theres some pretty extensive documentation/examples on the ghc wiki/trac (though perhaps a more extensive exposition for normal haskellers is called for too?) On Wed, Nov 27, 2013 at 1:18 PM, Henning Thielemann < lemming at henning-thielemann.de> wrote: > > On Wed, 27 Nov 2013, Richard Eisenberg wrote: > > It seems that the syntax and semantics of role annotations has settled, >> and so it's time to add role annotations to various libraries. >> > > This topic is completely new to me. Where can I read what it is about, > what is its motivation? > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Wed Nov 27 19:28:47 2013 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Wed, 27 Nov 2013 11:28:47 -0800 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: References: <1384961876.7607.186.camel@dunky.localdomain> Message-ID: Okay - to put a concrete proposal on this: 1) Include dlist-0.6, which would have the additions that Sean L. has proposed 2) Include scientific as package 3) Include an aeson that is updated to use the above two packages (and won't use blaze-builder) ?*Sean* - do you have a time frame for such changes? *Bas* - do you feel the API of scientific is solid enough to go into the platform? Are you willing to commit to the stability needs of the platform(*) *Bryan* - are you ready to turn out an aeson version that uses the above once they are out? *Everyone else* - After all the conversations, do we feel the rough consensus is to go ahead with these. In particular the changes that Sean proposed for dlist, and the inclusion of scientific. I realize this is Thanksgiving week in the U.S. - but let's hope we can come to a close on this by next Tuesday - Dec 3rd. Preferably sooner! - Mark (*): Meaning, the package would remain backward compatible for a few revs with ample deprecation time before altering APIs that would break code -- even through major version number changes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwlato at gmail.com Wed Nov 27 20:35:47 2013 From: jwlato at gmail.com (John Lato) Date: Wed, 27 Nov 2013 12:35:47 -0800 Subject: role signatures in libraries In-Reply-To: <871C45BC-6380-4809-A812-C7E3B82AA69E@cis.upenn.edu> References: <871C45BC-6380-4809-A812-C7E3B82AA69E@cis.upenn.edu> Message-ID: Hi Richard, Thanks very much for your work on this, I think the roles stuff looks quite useful. I would like to go through another example to make sure I understand this properly. Consider data V a = V Int (ForeignPtr a), a storable vector, where the Int is the number of elements. We would then want to add 'type role V nominal' as the stored data depends on the Storable instance for the 'a' parameter. Is this correct? To me it looks like a next step would be a way to specify that two representationally-equal types share a dictionary, and thus could be considered nominally equal for that dictionary. This would mean if we use newtype MkAge = MkAge Int deriving Storable (via GeneralizedNewtypeDeriving), we could then coerce V Int to V MkAge. We don't currently have a way to do this, correct? Thanks again for all your work on this! On Nov 27, 2013 10:05 AM, "Richard Eisenberg" wrote: > Hi libraries, > > It seems that the syntax and semantics of role annotations has settled, > and so it's time to add role annotations to various libraries. Here are the > key ideas: > > tl;dr: Add nominal role annotations for abstract datatypes whose data has > an invariant based on a class instance. Set and Map are top candidates. > > - We have three notions of equality: nominal, representational, and > phantom. > > - Type equality as we know it is called *nominal*. > > - A newtype is considered *representationally* equal to its representation > type. > * Thus, if we have `newtype Age = MkAge Int`, `Age` and `Int` are > representationally equal. > > - Any two types are "phantomly" equal. > * See below for an illustrative example of why this notion is useful. > > - Every type parameter of every datatype and class is assigned a role. A > parameter's role says what notion of equality must hold to show that two > instantiations of the datatype are representationally equal. > * Say we have `Bar a` where a's role is nominal. That means that `Bar > Age` is *not* representationally equal to `Bar Int`. > * Say we have `Foo a` where a's role is representational. That means > that `Foo Age` is representationally equal to `Foo Int`. > * Say we have `Quux a` where a's role is phantom. That means that `Quux > Int` is representationally equal to `Quux Bool`. > > - Datatype roles are inferred to be the most permissive possible. > * `data Bar a = MkBar (F a)` where `F` is a type family: a's role will > be inferred to be nominal. > * `data Foo a = MkFoo a`: a's role will be inferred to be > representational. > * `data Quux a = MkQuux String`: a's role will be inferred to be > phantom. > > - Class roles are inferred to be nominal. > * This choice follows from the idea that the dictionaries for `Ord Int` > and `Ord Age` should not be assumed to be the same. > > - A role annotation can be used to change a parameter's role. The syntax > is a top-level declaration `type role `. You need > the extension RoleAnnotations to use these. Role names are spelled out > (nominal, representational, phantom) and are in lower-case. > * If we wanted, say, Quux's parameter's role to be representational, we > could say `type role Quux representational`. > > - Role annotations must be in the same module as a type is defined in. > > - Roles can be left out by inserting `_`. This causes the role to be > inferred. > > - Role annotations cannot be used to undercut type safety. They are > checked to make sure they meet this requirement. > > - The new function `coerce` (in GHC.Exts) allows for 0-cost conversion > between representationally equal types. > * This means that converting [Quux Bool] to [Quux Int] is now free. > This is why phantom equality is interesting. > > - You should consider adding a role annotation on any type that has an > invariant based on class instances. > * For example, the information stored in a Set is ordered according to > the data's Ord instance. So, there should probably be an annotation `type > role Set nominal`. > * As a further example, the data stored in a Map cares about the Ord > instance of its first parameter but not its second. So, we would probably > want `type role Map nominal representational`. > > Note that the new roles stuff does *not* allow programmers to do more bad > things than they could previously. A sufficiently clever use of > GeneralizedNewtypeDeriving could invalidate any instance-based invariants > you wished to impose. However, we now have the power to stop these leaks of > abstraction. We also have, in `coerce`, an easier way to take advantage of > any remaining holes, making it even more important to close the gaps. > > The user manual is updated with respect to all the roles stuff -- you may > want to see there for more info. > > Please let me know if you have any questions about this! > Richard > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Wed Nov 27 21:40:42 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 27 Nov 2013 16:40:42 -0500 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: References: <1384961876.7607.186.camel@dunky.localdomain> Message-ID: I'm looking at the scientific package, and I thought to myself "huh, it doesn't seem to normalize the numbers to scientific notation" it has the right semantics for how printing and operations *mean*, but it doesn't seem to internally keep them as "normalized" floats. heres a snippet of a ghci transcript to illustrate this Prelude Data.Scientific> coefficient $ scientific 1000 2 1000 Prelude Data.Scientific> coefficient $ scientific 1 2 1 Prelude Data.Scientific> scientific 1000 2 100000.0 Prelude Data.Scientific> scientific 100 3 100000.0 Prelude Data.Scientific> coefficient $ scientific 10 4 10 Prelude Data.Scientific> scientific 10 4 100000.0 Prelude Data.Scientific> scientific 10 4 == scientific 1 5 True shoudn't an "exact" model of scientific notation format numbers keep them in normalized form? (ie clip the trailing zeros and such) On Wed, Nov 27, 2013 at 2:28 PM, Mark Lentczner wrote: > Okay - to put a concrete proposal on this: > > 1) Include dlist-0.6, which would have the additions that Sean L. has > proposed > 2) Include scientific as package > 3) Include an aeson that is updated to use the above two packages (and > won't use blaze-builder) > > ?*Sean* - do you have a time frame for such changes? > *Bas* - do you feel the API of scientific is solid enough to go into the > platform? Are you willing to commit to the stability needs of the > platform(*) > *Bryan* - are you ready to turn out an aeson version that uses the above > once they are out? > > *Everyone else* - After all the conversations, do we feel the rough > consensus is to go ahead with these. In particular the changes that Sean > proposed for dlist, and the inclusion of scientific. > > I realize this is Thanksgiving week in the U.S. - but let's hope we can > come to a close on this by next Tuesday - Dec 3rd. Preferably sooner! > > - Mark > > (*): Meaning, the package would remain backward compatible for a few revs > with ample deprecation time before altering APIs that would break code -- > even through major version number changes. > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Wed Nov 27 22:13:37 2013 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 27 Nov 2013 23:13:37 +0100 (CET) Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: References: <1384961876.7607.186.camel@dunky.localdomain> Message-ID: On Wed, 27 Nov 2013, Carter Schonwald wrote: > I'm looking at the scientific package, and I thought to myself "huh, it doesn't seem to normalize the > numbers to scientific notation" > it has the right semantics for how printing and operations *mean*, but it doesn't seem to internally keep > them as "normalized" floats. The mantissa is stored as Integer. I think that is the only way to keep all digits. But with that representation it is certainly not sensible to normalize to the most significant digit. A reasonable normalization might be to divide the mantissa by a power of 10 such that the mantissa is not a multiple of 10. From carter.schonwald at gmail.com Wed Nov 27 22:18:17 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 27 Nov 2013 17:18:17 -0500 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: References: <1384961876.7607.186.camel@dunky.localdomain> Message-ID: agreed, I think that would be a sensible choice. The key point being, every representable number should have a unique representation. On Wed, Nov 27, 2013 at 5:13 PM, Henning Thielemann < lemming at henning-thielemann.de> wrote: > > On Wed, 27 Nov 2013, Carter Schonwald wrote: > > I'm looking at the scientific package, and I thought to myself "huh, it >> doesn't seem to normalize the >> numbers to scientific notation" >> it has the right semantics for how printing and operations *mean*, but it >> doesn't seem to internally keep >> them as "normalized" floats. >> > > The mantissa is stored as Integer. I think that is the only way to keep > all digits. But with that representation it is certainly not sensible to > normalize to the most significant digit. A reasonable normalization might > be to divide the mantissa by a power of 10 such that the mantissa is not a > multiple of 10. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Wed Nov 27 22:32:11 2013 From: roma at ro-che.info (Roman Cheplyaka) Date: Thu, 28 Nov 2013 00:32:11 +0200 Subject: role signatures in libraries In-Reply-To: References: <871C45BC-6380-4809-A812-C7E3B82AA69E@cis.upenn.edu> Message-ID: <20131127223211.GB11020@sniper> * Carter Schonwald [2013-11-27 14:14:29-0500] > Richard has a paper or so on it, and theres some pretty extensive > documentation/examples on the ghc wiki/trac (though perhaps a more > extensive exposition for normal haskellers is called for too?) I find the explanation in Richard's email excellent ? very clear and accessible (except that, as Henning noted, it lacks the motivational part). Great job! Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From bos at serpentine.com Wed Nov 27 22:32:46 2013 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed, 27 Nov 2013 14:32:46 -0800 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: References: <1384961876.7607.186.camel@dunky.localdomain> Message-ID: On Wed, Nov 27, 2013 at 11:28 AM, Mark Lentczner wrote: > 1) Include dlist-0.6, which would have the additions that Sean L. has > proposed > 2) Include scientific as package > 3) Include an aeson that is updated to use the above two packages (and > won't use blaze-builder) > 4) Include a suitably new version of attoparsec (as yet unreleased) -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christian.Maeder at dfki.de Thu Nov 28 09:24:49 2013 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu, 28 Nov 2013 10:24:49 +0100 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: References: <1384961876.7607.186.camel@dunky.localdomain> Message-ID: <52970BE1.8040607@dfki.de> Hi, If the proposal is to include (at least) 3 packages that are not ready yet (on hackage) and attoparsec raises the question about how two different parser packages should coexist in the HP then, I think, aeson disqualifies itself to be included into the next HP 2013.4.0.0. Let's discuss and reconsider it in 2014. Cheers Christian Am 27.11.2013 23:32, schrieb Bryan O'Sullivan: > > On Wed, Nov 27, 2013 at 11:28 AM, Mark Lentczner > > wrote: > > 1) Include dlist-0.6, which would have the additions that Sean L. > has proposed > 2) Include scientific as package > 3) Include an aeson that is updated to use the above two packages > (and won't use blaze-builder) > > > 4) Include a suitably new version of attoparsec (as yet unreleased) > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From roma at ro-che.info Thu Nov 28 10:40:12 2013 From: roma at ro-che.info (Roman Cheplyaka) Date: Thu, 28 Nov 2013 12:40:12 +0200 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: <52970BE1.8040607@dfki.de> References: <1384961876.7607.186.camel@dunky.localdomain> <52970BE1.8040607@dfki.de> Message-ID: <20131128104012.GA19356@sniper> * Christian Maeder [2013-11-28 10:24:49+0100] > and attoparsec raises the question about how two different parser > packages should coexist in the HP I must have missed that ? what is the question, exactly? Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From hesselink at gmail.com Thu Nov 28 11:10:02 2013 From: hesselink at gmail.com (Erik Hesselink) Date: Thu, 28 Nov 2013 12:10:02 +0100 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: <52970BE1.8040607@dfki.de> References: <1384961876.7607.186.camel@dunky.localdomain> <52970BE1.8040607@dfki.de> Message-ID: On Thu, Nov 28, 2013 at 10:24 AM, Christian Maeder wrote: > If the proposal is to include (at least) 3 packages that are not ready yet > (on hackage) and attoparsec raises the question about how two different > parser packages should coexist in the HP then, I think, aeson disqualifies > itself to be included into the next HP 2013.4.0.0. Let's discuss and > reconsider it in 2014. I think this is a bad idea, since nothing will have changed substantially between now and 2014, so we'll only be postponing a discussion we might as well have now. Erik From Christian.Maeder at dfki.de Thu Nov 28 11:27:30 2013 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu, 28 Nov 2013 12:27:30 +0100 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: <20131128104012.GA19356@sniper> References: <1384961876.7607.186.camel@dunky.localdomain> <52970BE1.8040607@dfki.de> <20131128104012.GA19356@sniper> Message-ID: <529728A2.2000004@dfki.de> Am 28.11.2013 11:40, schrieb Roman Cheplyaka: > * Christian Maeder [2013-11-28 10:24:49+0100] >> and attoparsec raises the question about how two different parser >> packages should coexist in the HP > > I must have missed that ? what is the question, exactly? What is the recommended parser package of the HP to use when I start writing parsers? C. > > Roman > From Christian.Maeder at dfki.de Thu Nov 28 11:45:21 2013 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu, 28 Nov 2013 12:45:21 +0100 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: References: <1384961876.7607.186.camel@dunky.localdomain> <52970BE1.8040607@dfki.de> Message-ID: <52972CD1.3040605@dfki.de> Am 28.11.2013 12:10, schrieb Erik Hesselink: > On Thu, Nov 28, 2013 at 10:24 AM, Christian Maeder > wrote: >> If the proposal is to include (at least) 3 packages that are not ready yet >> (on hackage) and attoparsec raises the question about how two different >> parser packages should coexist in the HP then, I think, aeson disqualifies >> itself to be included into the next HP 2013.4.0.0. Let's discuss and >> reconsider it in 2014. > > I think this is a bad idea, since nothing will have changed > substantially between now and 2014, so we'll only be postponing a > discussion we might as well have now. I don't mind discussing (now or later), but shouldn't the exact implications be made clear before? Was the inclusion of attoparsec discussed before? (I may have missed it, though.) If the packages to be updated (aeson) or extended (dlist) or made "suitably" new (attoparsec) are not on hackage yet, how can the "requirement for API stability before inclusion in the HP" be met? Cheers Christian > > Erik > > From svenpanne at gmail.com Thu Nov 28 12:42:19 2013 From: svenpanne at gmail.com (Sven Panne) Date: Thu, 28 Nov 2013 13:42:19 +0100 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: <52972CD1.3040605@dfki.de> References: <1384961876.7607.186.camel@dunky.localdomain> <52970BE1.8040607@dfki.de> <52972CD1.3040605@dfki.de> Message-ID: Just two add my 2c: Given all these new packages which would need to be pulled into the HP just for aeson, let's not include aeson for 2013.4.0.0 and release 2013.4.0.0 soon without the need for lengthy discussions. One of the main points of the HP is stability, and doing things in a useless rush now just to get one more package in is not the right way to proceed IMHO. We had *tons* of discussions in the past about minor details and now we should pull lots of largely unreviewed/unreleased/unstable things in a hurry? That would miss the main motivation behind the HP. IMHO a package which is (about to be) included in the API has quite a few constraints: Its API has to be stable, but its dependencies have to be stable, too, and they have to be in the HP as well. You can't simply use tons of other stuff just because it's convenient. Things have to be more self-contained than in "normal" packages. Yes, that's a bit of a burden for the maintainer, but OTOH that's the price one has to play for almost universal adoption of one's package. From sean.leather at gmail.com Thu Nov 28 13:35:50 2013 From: sean.leather at gmail.com (Sean Leather) Date: Thu, 28 Nov 2013 15:35:50 +0200 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: References: <1384961876.7607.186.camel@dunky.localdomain> Message-ID: On Wed, Nov 27, 2013 at 9:28 PM, Mark Lentczner wrote: > Okay - to put a concrete proposal on this: > > 1) Include dlist-0.6, which would have the additions that Sean L. has > proposed > [...] > ?*Sean* - do you have a time frame for such changes? > [...] dlist-0.6 is ready for imminent release. Just waiting on the Hackage admins. I also ran the test suite in the aeson HEAD with the dlist HEAD just to check. Regards, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Thu Nov 28 13:52:04 2013 From: roma at ro-che.info (Roman Cheplyaka) Date: Thu, 28 Nov 2013 15:52:04 +0200 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: <529728A2.2000004@dfki.de> References: <1384961876.7607.186.camel@dunky.localdomain> <52970BE1.8040607@dfki.de> <20131128104012.GA19356@sniper> <529728A2.2000004@dfki.de> Message-ID: <20131128135204.GA5427@sniper> * Christian Maeder [2013-11-28 12:27:30+0100] > Am 28.11.2013 11:40, schrieb Roman Cheplyaka: > >* Christian Maeder [2013-11-28 10:24:49+0100] > >>and attoparsec raises the question about how two different parser > >>packages should coexist in the HP > > > >I must have missed that ? what is the question, exactly? > > What is the recommended parser package of the HP to use when I start > writing parsers? Depends on what kind of parser you're writing. Parsec is for things that humans typically write ? like programs and config files. When the speed is not an issue, and good error messages are required. Attoparsec is for machine-generated formats, where you need performance but error messages are not so critical. So there's not that much overlap between these packages, although they both deal with parsing. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From v.dijk.bas at gmail.com Thu Nov 28 16:42:49 2013 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Thu, 28 Nov 2013 17:42:49 +0100 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: References: <1384961876.7607.186.camel@dunky.localdomain> <52970BE1.8040607@dfki.de> <52972CD1.3040605@dfki.de> Message-ID: On 28 November 2013 13:42, Sven Panne wrote: > Just two add my 2c: Given all these new packages which would need to > be pulled into the HP just for aeson, let's not include aeson for > 2013.4.0.0 and release 2013.4.0.0 soon without the need for lengthy > discussions. As the proposer for inclusion of aeson in the HP I'm beginning to agree. There's another reason I would like to postpone the aeson inclusion: I just started working on improving the encoding performance of aeson. This requires some significant changes to the API. Therefore I think it would be better to see how well this new API works out. If it works out, release it as aeson-7 (or aeson-8) and include that release in the HP after next. This way we have time to discuss the new dependencies and the HP remains stable. The following is a brief explanation of the new aeson API (you can stop reading here if you're not interested in it): The idea is to use the same trick that is used in the upcoming binary package[1]. First of all toJSON will return a JsonBuilder instead of a Value: class ToJSON a where toJSON :: a -> JsonBuilder A JsonBuilder is basically a difference list: newtype JsonBuilder = JsonBuilder (IStream -> IStream) instance Monoid JsonBuilder where ... The "list", here represented as an IStream, is a sequence of instructions to the encoder: data IStream = INull IStream | ITrue IStream | IFalse IStream | IDoubleQuote IStream | IChar {-# UNPACK #-} !Char IStream | IString !String IStream | IText !Text IStream | IInt {-# UNPACK #-} !Int IStream | IInt8 {-# UNPACK #-} !Int8 IStream | IInt16 {-# UNPACK #-} !Int16 IStream | IInt32 {-# UNPACK #-} !Int32 IStream | IInt64 {-# UNPACK #-} !Int64 IStream | IWord {-# UNPACK #-} !Word IStream | IWord8 {-# UNPACK #-} !Word8 IStream | IWord16 {-# UNPACK #-} !Word16 IStream | IWord32 {-# UNPACK #-} !Word32 IStream | IWord64 {-# UNPACK #-} !Word64 IStream | IFloat {-# UNPACK #-} !Float IStream | IDouble {-# UNPACK #-} !Double IStream | IInteger !Integer IStream | IScientific !Scientific IStream | IComma IStream | IBeginArray IStream | IEndArray IStream | IBeginObject IStream | IEndObject IStream | IColon IStream | IValue !Value IStream -- Fused: | IBeginObject_IDoubleQuote IStream | IComma_IDoubleQuote IStream -- TODO; more | IEnd Converting a JsonBuilder to a Builder (note that I'm using the new bytestring Builder here) is simply a matter of executing the right Builder for each instruction: toBuilder :: JsonBuilder -> Builder toBuilder (JsonBuilder g) = go (g IEnd) where go :: IStream -> Builder go is = case is of INull is' -> nullB <> go is' ITrue is' -> trueB <> go is' IFalse is' -> falseB <> go is' IDoubleQuote is' -> char8 '"' <> go is' IChar c is' -> char c <> go is' IString cs is' -> string cs <> go is' IText t is' -> text t <> go is' IInt i is' -> intDec i <> go is' IInt8 i8 is' -> int8Dec i8 <> go is' IInt16 i16 is' -> int16Dec i16 <> go is' IInt32 i32 is' -> int32Dec i32 <> go is' IInt64 i64 is' -> int64Dec i64 <> go is' IWord w is' -> wordDec w <> go is' IWord8 w8 is' -> word8Dec w8 <> go is' IWord16 w16 is' -> word16Dec w16 <> go is' IWord32 w32 is' -> word32Dec w32 <> go is' IWord64 w64 is' -> word64Dec w64 <> go is' IFloat f is' -> floatDec f <> go is' IDouble d is' -> doubleDec d <> go is' IInteger i is' -> integerDec i <> go is' IScientific s is' -> fromScientific s <> go is' IComma is' -> char8 ',' <> go is' IBeginArray is' -> char8 '[' <> go is' IEndArray is' -> char8 ']' <> go is' IBeginObject is' -> char8 '{' <> go is' IEndObject is' -> char8 '}' <> go is' IColon is' -> char8 ':' <> go is' IValue v is' -> fromValue v <> go is' -- Fused: IBeginObject_IDoubleQuote is'-> fixed2('{','"')<> go is' IComma_IDoubleQuote is'-> fixed2(',','"')<> go is' -- TODO: more IEnd -> mempty nullB :: Builder nullB = fixed4 ('n',('u',('l','l'))) {-# INLINE nullB #-} trueB :: Builder trueB = fixed4 ('t',('r',('u','e'))) {-# INLINE trueB #-} falseB :: Builder falseB = fixed5 ('f',('a',('l',('s','e')))) {-# INLINE falseB #-} fixed2 :: (Char, Char) -> Builder fixed2 = P.primFixed (P.char8 >*< P.char8) {-# INLINE fixed2 #-} fixed4 :: (Char, (Char, (Char, Char))) -> Builder fixed4 = P.primFixed (P.char8 >*< P.char8 >*< P.char8 >*< P.char8) {-# INLINE fixed4 #-} fixed5 :: (Char, (Char, (Char, (Char, Char)))) -> Builder fixed5 = P.primFixed (P.char8 >*< P.char8 >*< P.char8 >*< P.char8 >*< P.char8) {-# INLINE fixed5 #-} This representation allows a lot of optimizations. For example we can define rewrite rules that "fuse" the Builders of common sequences like: {-# RULES "IBeginObject_IDoubleQuote" forall is. IBeginObject (IDoubleQuote is) = IBeginObject_IDoubleQuote is #-} {-# RULES "IComma_IDoubleQuote" forall is. IComma (IDoubleQuote is) = IComma_IDoubleQuote is #-} The encoder can handle these common sequences more efficiently. Of course the JsonBuilder is abstract to the user. There will be a safe API to construct well-formed JsonBuilders. (While writing this I realize that users will be able to use the Monoid instance for JsonBuilders which is undesirable. I will solve this by wrapping the JsonBuilder returned from toJSON in another newtype which doesn't have a Monoid instance) What do we loose? In the current API of aeson, toJSON will directly return a Value. This Value can then be inspected or extended. In order to do the same in the new API the JsonBuilder first has to be parsed to a Value which is less efficient. However, if the new API proves to be significantly more efficient for encoding I think this extra parsing cost is warranted since it's far less common than encoding. A first version of this API will soon be ready and I will push that to my github. Hopefully I can come up with some convincing benchmarks! Bas From spam at scientician.net Thu Nov 28 19:19:00 2013 From: spam at scientician.net (Bardur Arantsson) Date: Thu, 28 Nov 2013 20:19:00 +0100 Subject: aeson and dlist in HP 2013.4.0.0 In-Reply-To: References: <1384961876.7607.186.camel@dunky.localdomain> <52970BE1.8040607@dfki.de> <52972CD1.3040605@dfki.de> Message-ID: On 2013-11-28 17:42, Bas van Dijk wrote: > On 28 November 2013 13:42, Sven Panne wrote: >> Just two add my 2c: Given all these new packages which would need to >> be pulled into the HP just for aeson, let's not include aeson for >> 2013.4.0.0 and release 2013.4.0.0 soon without the need for lengthy >> discussions. > > As the proposer for inclusion of aeson in the HP I'm beginning to agree. > > There's another reason I would like to postpone the aeson inclusion: I > just started working on improving the encoding performance of aeson. > This requires some significant changes to the API. Therefore I think > it would be better to see how well this new API works out. If it works > out, release it as aeson-7 (or aeson-8) and include that release in > the HP after next. This way we have time to discuss the new > dependencies and the HP remains stable. > [--snip lots of interesting details--] You mentioned generating JSON, so I just thought I'd mention that it might also be possible to speed up *parsing* hugely, assuming that only a few fields/values are needed/evaluated. There's a very interesting paper called "Semi-Indexing Semi-Structured Data in Tiny Space" (G. Ottaviano, R. Grossi, 2011) which basically skips the whole "parsing" overhead in favor of only "scanning" overhead in its approach to parsing -- which seems to compare very favorably to C/C++ code for parsing JSON. In addition it uses space-efficient data structures for all intermediate data, so it may even pay to build a semi-index and then use that to parse even in one-off situations. (Credit where credit's due: I think it was Edward Kmett who posted a comment with this reference on Reddit. I think he mentioned something about pursuing this for Lens in his Copious Spare Time(TM)?). I'm not sure how this work could be integrated with Aeson, but I'm betting somebody out there has good ideas. Aeson is already extremely good, but let's make it even better! ... and by "us", I mean "you, dear Haskell community". Regards, From johan.tibell at gmail.com Fri Nov 29 12:07:58 2013 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri, 29 Nov 2013 13:07:58 +0100 Subject: Proposal: Add a strict version of <$> for monads Message-ID: Hi all, I propose we add a strict version of <$> to base: -- | A strict version of 'Data.Functor.<$>' for monads. (<$!>) :: Monad m => (a -> b) -> m a -> m b f <$!> m = do a <- m return $! f a {-# INLINE (<$!>) #-} infixl 4 <$!> It works on Monads instead of Functors as required by us inspecting the argument. This version is highly convenient if you want to work with functors/applicatives in e.g. parser and avoid spurious thunks at the same time. I realized that it was needed while fixing large space usage (but not space-leak) issues in cassava. I believe Edward Kmett discovered the need for it independently as well. Deadline: 3 weeks Cheers, Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at gregorycollins.net Fri Nov 29 12:14:01 2013 From: greg at gregorycollins.net (Gregory Collins) Date: Fri, 29 Nov 2013 13:14:01 +0100 Subject: Proposal: Add a strict version of <$> for monads In-Reply-To: References: Message-ID: Obvious +1. On Fri, Nov 29, 2013 at 1:07 PM, Johan Tibell wrote: > Hi all, > > I propose we add a strict version of <$> to base: > > -- | A strict version of 'Data.Functor.<$>' for monads. > (<$!>) :: Monad m => (a -> b) -> m a -> m b > f <$!> m = do > a <- m > return $! f a > {-# INLINE (<$!>) #-} > > infixl 4 <$!> > > It works on Monads instead of Functors as required by us inspecting the > argument. > > This version is highly convenient if you want to work with > functors/applicatives in e.g. parser and avoid spurious thunks at the same > time. I realized that it was needed while fixing large space usage (but not > space-leak) issues in cassava. > > I believe Edward Kmett discovered the need for it independently as well. > > Deadline: 3 weeks > > Cheers, > Johan > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -- Gregory Collins -------------- next part -------------- An HTML attachment was scrubbed... URL: From twanvl at gmail.com Fri Nov 29 12:19:53 2013 From: twanvl at gmail.com (Twan van Laarhoven) Date: Fri, 29 Nov 2013 12:19:53 +0000 Subject: Proposal: Add a strict version of <$> for monads In-Reply-To: References: Message-ID: <52988669.4070706@gmail.com> I don't like that this function is implemented for Monads, I think that it makes sense for some other functors as well. Though to do this 'properly' we would probably end up with another typeclass "StrictFunctor" or something, and that is perhaps too much unnecessary complexity. In the same vein as strict fmap, does a strict (<*>) make sense as well? -- | A strict version of `Control.Applicative.<*>` for monads (<*!>) :: Monad m => m (a -> b) -> m a -> m b mf <*!> mx = do f <- mf x <- mx return $! f x We might also call these fmap' and ap', but I prefer the operator. Twan On 29/11/13 12:07, Johan Tibell wrote: > Hi all, > > I propose we add a strict version of <$> to base: > > -- | A strict version of 'Data.Functor.<$>' for monads. > (<$!>) :: Monad m => (a -> b) -> m a -> m b > f <$!> m = do > a <- m > return $! f a > {-# INLINE (<$!>) #-} > > infixl 4 <$!> > > It works on Monads instead of Functors as required by us inspecting the argument. > > This version is highly convenient if you want to work with functors/applicatives > in e.g. parser and avoid spurious thunks at the same time. I realized that it > was needed while fixing large space usage (but not space-leak) issues in cassava. > > I believe Edward Kmett discovered the need for it independently as well. > > Deadline: 3 weeks > > Cheers, > Johan > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From johan.tibell at gmail.com Fri Nov 29 12:23:40 2013 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri, 29 Nov 2013 13:23:40 +0100 Subject: Proposal: Add a strict version of <$> for monads In-Reply-To: <52988669.4070706@gmail.com> References: <52988669.4070706@gmail.com> Message-ID: On Fri, Nov 29, 2013 at 1:19 PM, Twan van Laarhoven wrote: > I don't like that this function is implemented for Monads, I think that it > makes sense for some other functors as well. Though to do this 'properly' > we would probably end up with another typeclass "StrictFunctor" or > something, and that is perhaps too much unnecessary complexity. Do you have an example of such a functor? -- Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dluposchainsky at googlemail.com Fri Nov 29 12:32:48 2013 From: dluposchainsky at googlemail.com (David Luposchainsky) Date: Fri, 29 Nov 2013 13:32:48 +0100 Subject: Proposal: Add a strict version of <$> for monads In-Reply-To: <52988669.4070706@gmail.com> References: <52988669.4070706@gmail.com> Message-ID: <52988970.4030105@gmail.com> On 29.11.2013 13:19, Twan van Laarhoven wrote: > In the same vein as strict fmap, does a strict (<*>) make sense as well? I think this brings up a good point: strictness annotations may make sense in multiple other scenarios, not just for fmap. Can't we encapsulate similar functionality in a separate function first, wait for it to settle, and then introduce infix versions of it if really necessary? What about seqM :: Monad m => m a -> m a seqM m = m >>= (return $!) This would allow local definitions of f <$!> x = seqM (f <$> x) mf <*!> mx = seqM (mf <*> mx) until the dust settles. If <$!> is really used in abundance, then add <$!> as an infix. The reason why I'm hesitant to introduce a new infix for this is because I think infix is generally less readable than letter-based names. I agree that infix is good to have for functions you use a lot -- to the point where the infix is the standard application, like >>= and <$> -- but for <$!> I don't see this (yet). David From dluposchainsky at googlemail.com Fri Nov 29 12:35:52 2013 From: dluposchainsky at googlemail.com (David Luposchainsky) Date: Fri, 29 Nov 2013 13:35:52 +0100 Subject: Proposal: Add a strict version of <$> for monads In-Reply-To: References: <52988669.4070706@gmail.com> Message-ID: <52988A28.8060307@gmail.com> On 29.11.2013 13:23, Johan Tibell wrote: > On Fri, Nov 29, 2013 at 1:19 PM, Twan van Laarhoven > > I don't like that this function is implemented for Monads, I think > that it makes sense for some other functors as well. Though to do > this 'properly' we would probably end up with another typeclass > "StrictFunctor" or something, and that is perhaps too much > unnecessary complexity. > > > Do you have an example of such a functor? Async is a Functor (but not Applicative). When asyncs finish and you poll their result with `wait`, you potentially get back an IO . (Just the first example that came to mind.) David From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Fri Nov 29 12:44:09 2013 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Fri, 29 Nov 2013 12:44:09 +0000 Subject: Proposal: Add a strict version of <$> for monads In-Reply-To: <52988970.4030105@gmail.com> References: <52988669.4070706@gmail.com> <52988970.4030105@gmail.com> Message-ID: <20131129124409.GA28252@weber> On Fri, Nov 29, 2013 at 01:32:48PM +0100, David Luposchainsky wrote: > On 29.11.2013 13:19, Twan van Laarhoven wrote: > > In the same vein as strict fmap, does a strict (<*>) make sense as well? > > I think this brings up a good point: strictness annotations may make > sense in multiple other scenarios, not just for fmap. Can't we > encapsulate similar functionality in a separate function first, wait for > it to settle, and then introduce infix versions of it if really necessary? > > What about > > seqM :: Monad m => m a -> m a > seqM m = m >>= (return $!) I think this is an excellent idea. It makes sense to address the issue in the simplest, most generic way possible first and then later provide specialised functions when they have been shown to have widespread real-world usage. Tom (PS I note this is yet another example of the invisible Thunk type constructor causing problems!) From ivan.miljenovic at gmail.com Fri Nov 29 12:42:48 2013 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Fri, 29 Nov 2013 23:42:48 +1100 Subject: Proposal: Add a strict version of <$> for monads In-Reply-To: <52988A28.8060307@gmail.com> References: <52988669.4070706@gmail.com> <52988A28.8060307@gmail.com> Message-ID: On 29 November 2013 23:35, David Luposchainsky wrote: > On 29.11.2013 13:23, Johan Tibell wrote: >> On Fri, Nov 29, 2013 at 1:19 PM, Twan van Laarhoven >> >> I don't like that this function is implemented for Monads, I think >> that it makes sense for some other functors as well. Though to do >> this 'properly' we would probably end up with another typeclass >> "StrictFunctor" or something, and that is perhaps too much >> unnecessary complexity. >> >> >> Do you have an example of such a functor? > > Async is a Functor (but not Applicative). When asyncs finish and you > poll their result with `wait`, you potentially get back an IO . > (Just the first example that came to mind.) Except wait :: Async a -> IO a, so it's actually in the IO monad (which _is_ a monad :p). I'm +1 -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From dluposchainsky at googlemail.com Fri Nov 29 12:47:47 2013 From: dluposchainsky at googlemail.com (David Luposchainsky) Date: Fri, 29 Nov 2013 13:47:47 +0100 Subject: Proposal: Add a strict version of <$> for monads In-Reply-To: References: <52988669.4070706@gmail.com> <52988A28.8060307@gmail.com> Message-ID: <52988CF3.8030302@gmail.com> On 29.11.2013 13:42, Ivan Lazar Miljenovic wrote: > On 29 November 2013 23:35, David Luposchainsky > wrote: > >> Async is a Functor (but not Applicative). When asyncs finish and you >> poll their result with `wait`, you potentially get back an IO . >> (Just the first example that came to mind.) > > Except wait :: Async a -> IO a, so it's actually in the IO monad > (which _is_ a monad :p). Sure, but now you're in IO (and can $! in IO of course). But sometimes you may not want to `wait` just yet, and evaluate the Async's eventual result directly to WHNF, so that if you then `wait`, you get an already evaluated thing in IO. From johan.tibell at gmail.com Fri Nov 29 14:04:13 2013 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri, 29 Nov 2013 15:04:13 +0100 Subject: Proposal: Add a strict version of <$> for monads In-Reply-To: <52988970.4030105@gmail.com> References: <52988669.4070706@gmail.com> <52988970.4030105@gmail.com> Message-ID: On Fri, Nov 29, 2013 at 1:32 PM, David Luposchainsky < dluposchainsky at googlemail.com> wrote: > On 29.11.2013 13:19, Twan van Laarhoven wrote: > > In the same vein as strict fmap, does a strict (<*>) make sense as well? > > I think this brings up a good point: strictness annotations may make > sense in multiple other scenarios, not just for fmap. Can't we > encapsulate similar functionality in a separate function first, wait for > it to settle, and then introduce infix versions of it if really necessary? > > What about > > seqM :: Monad m => m a -> m a > seqM m = m >>= (return $!) > > This would allow local definitions of > > f <$!> x = seqM (f <$> x) > mf <*!> mx = seqM (mf <*> mx) > > until the dust settles. If <$!> is really used in abundance, then add > <$!> as an infix. > I think this is a good idea. We still need to think about how to make it clear to users when they need to force things when writing functorial (sp?)/applicative/monadic code. It's quite easy to introduce additional thunks there as expressions are often pushed inside a lazy data type (e.g. the state monad pushes the value inside a lazy tuple). If you look at e.g. the applicative APIs or some code that use them (e.g. attoparsec), it's not obvious that you can shoot yourself in the foot pretty easily by introducing too many thunks and thus use more space than needed. I ran into this in practice when working with attoparsec. If you use e.g. the provided sepBy combinator, you end up with a list of many thunks in it. We ended up adding strict versions of basically all the combinators to work around this. -- Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From twanvl at gmail.com Fri Nov 29 14:50:26 2013 From: twanvl at gmail.com (Twan van Laarhoven) Date: Fri, 29 Nov 2013 14:50:26 +0000 Subject: Proposal: Add a strict version of <$> for monads In-Reply-To: References: <52988669.4070706@gmail.com> Message-ID: <5298A9B2.9080607@gmail.com> On 29/11/13 12:23, Johan Tibell wrote: > On Fri, Nov 29, 2013 at 1:19 PM, Twan van Laarhoven > wrote: > > I don't like that this function is implemented for Monads, I think that it > makes sense for some other functors as well. Though to do this 'properly' we > would probably end up with another typeclass "StrictFunctor" or something, > and that is perhaps too much unnecessary complexity. > > > Do you have an example of such a functor? > > -- Johan The first thing that came to mind was ZipList. Perhaps a more realistic example would be parsing combinator or FRP libraries that are applicative but not monadic. Twan From johan.tibell at gmail.com Fri Nov 29 15:35:24 2013 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri, 29 Nov 2013 16:35:24 +0100 Subject: Proposal: Add a strict version of <$> for monads In-Reply-To: <5298A9B2.9080607@gmail.com> References: <52988669.4070706@gmail.com> <5298A9B2.9080607@gmail.com> Message-ID: I'm trying to figure out whether this is a property of the functor itself. I guess it is, but at the same time it seems somewhat orthogonal whether to `seq` some value`. On Fri, Nov 29, 2013 at 3:50 PM, Twan van Laarhoven wrote: > On 29/11/13 12:23, Johan Tibell wrote: > >> On Fri, Nov 29, 2013 at 1:19 PM, Twan van Laarhoven > > wrote: >> >> I don't like that this function is implemented for Monads, I think >> that it >> makes sense for some other functors as well. Though to do this >> 'properly' we >> would probably end up with another typeclass "StrictFunctor" or >> something, >> and that is perhaps too much unnecessary complexity. >> >> >> Do you have an example of such a functor? >> >> -- Johan >> > > The first thing that came to mind was ZipList. Perhaps a more realistic > example would be parsing combinator or FRP libraries that are applicative > but not monadic. > > > Twan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Nov 29 17:03:43 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 29 Nov 2013 12:03:43 -0500 Subject: Proposal: Add a strict version of <$> for monads In-Reply-To: References: <52988669.4070706@gmail.com> <5298A9B2.9080607@gmail.com> Message-ID: could someone explain to me why this <$!> would be for monads rather being more generally also for functors or applicatives? On Fri, Nov 29, 2013 at 10:35 AM, Johan Tibell wrote: > I'm trying to figure out whether this is a property of the functor itself. > I guess it is, but at the same time it seems somewhat orthogonal whether to > `seq` some value`. > > > On Fri, Nov 29, 2013 at 3:50 PM, Twan van Laarhoven wrote: > >> On 29/11/13 12:23, Johan Tibell wrote: >> >>> On Fri, Nov 29, 2013 at 1:19 PM, Twan van Laarhoven >> > wrote: >>> >>> I don't like that this function is implemented for Monads, I think >>> that it >>> makes sense for some other functors as well. Though to do this >>> 'properly' we >>> would probably end up with another typeclass "StrictFunctor" or >>> something, >>> and that is perhaps too much unnecessary complexity. >>> >>> >>> Do you have an example of such a functor? >>> >>> -- Johan >>> >> >> The first thing that came to mind was ZipList. Perhaps a more realistic >> example would be parsing combinator or FRP libraries that are applicative >> but not monadic. >> >> >> Twan >> > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Fri Nov 29 18:42:57 2013 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Fri, 29 Nov 2013 18:42:57 +0000 Subject: Proposal: Add a strict version of <$> for monads In-Reply-To: References: <52988669.4070706@gmail.com> <5298A9B2.9080607@gmail.com> Message-ID: <20131129184257.GC28252@weber> On Fri, Nov 29, 2013 at 12:03:43PM -0500, Carter Schonwald wrote: > could someone explain to me why this <$!> would be for monads rather being > more generally also for functors or applicatives? It's not clear whether such a thing can be implemented for a functor or applicative. It seemingly needs to exploit the fact that the next action in a bind can depend on the "value returned by" the previous action. Still, the semantics depend very much on the laziness properties of the monad in question. f <$!> m = do a <- m return $! f a data R x = R x data S x = S x data T x = T x instance Monad T where return = T m >>= f = T (case m of T m' -> case f m' of T y -> y) instance Monad S where return = S m >>= f = case m of S m' -> S (case f m' of S y -> y) -- Equivalent implementation -- S m' >>= f = S (case f m' of S y -> y) instance Monad R where return = R m >>= f = case m of R m' -> case f m' of R y -> R y -- Equivalent implementations: -- m >>= f = case m of R m' -> f m' -- R m' >>= f = f m' try :: Monad m => m Int -> () try l = (+1) <$!> l `seq` () *Main> try (undefined :: T Int) () *Main> try (T undefined :: T Int) () *Main> try (undefined :: S Int) *** Exception: Prelude.undefined *Main> try (S undefined :: S Int) () *Main> try (undefined :: R Int) *** Exception: Prelude.undefined *Main> try (R undefined :: R Int) *** Exception: Prelude.undefined Tom From ekmett at gmail.com Fri Nov 29 23:11:36 2013 From: ekmett at gmail.com (Edward Kmett) Date: Fri, 29 Nov 2013 18:11:36 -0500 Subject: Proposal: Add a strict version of <$> for monads In-Reply-To: References: <52988669.4070706@gmail.com> <5298A9B2.9080607@gmail.com> Message-ID: Figure out how to write one using either of those APIs, and I'll be quite impressed. =) I personally use this quite often when working in a monad, in lieu of `return $!` games. The argument for implementing a version of it in terms of Monad and not some new class off to the side of the class hierarchy that Monad doesn't subclass is that, frankly, if such a thing existed, I'd still have to use this combinator anyways when working with a transformer stack, etc. and would derive little benefit. -Edward On Fri, Nov 29, 2013 at 12:03 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > could someone explain to me why this <$!> would be for monads rather being > more generally also for functors or applicatives? > > > On Fri, Nov 29, 2013 at 10:35 AM, Johan Tibell wrote: > >> I'm trying to figure out whether this is a property of the functor >> itself. I guess it is, but at the same time it seems somewhat orthogonal >> whether to `seq` some value`. >> >> >> On Fri, Nov 29, 2013 at 3:50 PM, Twan van Laarhoven wrote: >> >>> On 29/11/13 12:23, Johan Tibell wrote: >>> >>>> On Fri, Nov 29, 2013 at 1:19 PM, Twan van Laarhoven >>> > wrote: >>>> >>>> I don't like that this function is implemented for Monads, I think >>>> that it >>>> makes sense for some other functors as well. Though to do this >>>> 'properly' we >>>> would probably end up with another typeclass "StrictFunctor" or >>>> something, >>>> and that is perhaps too much unnecessary complexity. >>>> >>>> >>>> Do you have an example of such a functor? >>>> >>>> -- Johan >>>> >>> >>> The first thing that came to mind was ZipList. Perhaps a more realistic >>> example would be parsing combinator or FRP libraries that are applicative >>> but not monadic. >>> >>> >>> Twan >>> >> >> >> _______________________________________________ >> 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 johnw at fpcomplete.com Sat Nov 30 01:06:29 2013 From: johnw at fpcomplete.com (John Wiegley) Date: Fri, 29 Nov 2013 18:06:29 -0700 Subject: Proposal: Add a strict version of <$> for monads In-Reply-To: (Johan Tibell's message of "Fri, 29 Nov 2013 13:07:58 +0100") References: Message-ID: >>>>> Johan Tibell writes: > I propose we add a strict version of <$> to base: +1 John From nicolas at incubaid.com Sat Nov 30 01:11:02 2013 From: nicolas at incubaid.com (Nicolas Trangez) Date: Sat, 30 Nov 2013 02:11:02 +0100 Subject: Proposal: Add a strict version of <$> for monads In-Reply-To: References: <52988669.4070706@gmail.com> <5298A9B2.9080607@gmail.com> Message-ID: I'm without a doubt overlooking something, but couldn't this be (otoh) fmap' :: Functor f => (a -> b) -> f a -> f b fmap' f = fmap (strictify f) where strictify s = (($!) id) . s Nicolas On Nov 30, 2013 12:11 AM, "Edward Kmett" wrote: > Figure out how to write one using either of those APIs, and I'll be quite > impressed. =) > > I personally use this quite often when working in a monad, in lieu of > `return $!` games. > > The argument for implementing a version of it in terms of Monad and not > some new class off to the side of the class hierarchy that Monad doesn't > subclass is that, frankly, if such a thing existed, I'd still have to use > this combinator anyways when working with a transformer stack, etc. and > would derive little benefit. > > -Edward > > > On Fri, Nov 29, 2013 at 12:03 PM, Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> could someone explain to me why this <$!> would be for monads rather >> being more generally also for functors or applicatives? >> >> >> On Fri, Nov 29, 2013 at 10:35 AM, Johan Tibell wrote: >> >>> I'm trying to figure out whether this is a property of the functor >>> itself. I guess it is, but at the same time it seems somewhat orthogonal >>> whether to `seq` some value`. >>> >>> >>> On Fri, Nov 29, 2013 at 3:50 PM, Twan van Laarhoven wrote: >>> >>>> On 29/11/13 12:23, Johan Tibell wrote: >>>> >>>>> On Fri, Nov 29, 2013 at 1:19 PM, Twan van Laarhoven >>>> > wrote: >>>>> >>>>> I don't like that this function is implemented for Monads, I think >>>>> that it >>>>> makes sense for some other functors as well. Though to do this >>>>> 'properly' we >>>>> would probably end up with another typeclass "StrictFunctor" or >>>>> something, >>>>> and that is perhaps too much unnecessary complexity. >>>>> >>>>> >>>>> Do you have an example of such a functor? >>>>> >>>>> -- Johan >>>>> >>>> >>>> The first thing that came to mind was ZipList. Perhaps a more realistic >>>> example would be parsing combinator or FRP libraries that are applicative >>>> but not monadic. >>>> >>>> >>>> Twan >>>> >>> >>> >>> _______________________________________________ >>> 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 >> >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Sat Nov 30 11:05:06 2013 From: roma at ro-che.info (Roman Cheplyaka) Date: Sat, 30 Nov 2013 13:05:06 +0200 Subject: Proposal: Add a strict version of <$> for monads In-Reply-To: References: <52988669.4070706@gmail.com> <5298A9B2.9080607@gmail.com> Message-ID: <20131130110506.GA4626@sniper> No. Evaluation of your 'strictify' function will be delayed for the very same reason that evaluation of 'f' is delayed in the first place. It doesn't matter what 'strictify' *does* if it's not even evaluated. * Nicolas Trangez [2013-11-30 02:11:02+0100] > I'm without a doubt overlooking something, but couldn't this be (otoh) > > fmap' :: Functor f => (a -> b) -> f a -> f b > fmap' f = fmap (strictify f) > where > strictify s = (($!) id) . s > > Nicolas > On Nov 30, 2013 12:11 AM, "Edward Kmett" wrote: > > > Figure out how to write one using either of those APIs, and I'll be quite > > impressed. =) > > > > I personally use this quite often when working in a monad, in lieu of > > `return $!` games. > > > > The argument for implementing a version of it in terms of Monad and not > > some new class off to the side of the class hierarchy that Monad doesn't > > subclass is that, frankly, if such a thing existed, I'd still have to use > > this combinator anyways when working with a transformer stack, etc. and > > would derive little benefit. > > > > -Edward > > > > > > On Fri, Nov 29, 2013 at 12:03 PM, Carter Schonwald < > > carter.schonwald at gmail.com> wrote: > > > >> could someone explain to me why this <$!> would be for monads rather > >> being more generally also for functors or applicatives? > >> > >> > >> On Fri, Nov 29, 2013 at 10:35 AM, Johan Tibell wrote: > >> > >>> I'm trying to figure out whether this is a property of the functor > >>> itself. I guess it is, but at the same time it seems somewhat orthogonal > >>> whether to `seq` some value`. > >>> > >>> > >>> On Fri, Nov 29, 2013 at 3:50 PM, Twan van Laarhoven wrote: > >>> > >>>> On 29/11/13 12:23, Johan Tibell wrote: > >>>> > >>>>> On Fri, Nov 29, 2013 at 1:19 PM, Twan van Laarhoven >>>>> > wrote: > >>>>> > >>>>> I don't like that this function is implemented for Monads, I think > >>>>> that it > >>>>> makes sense for some other functors as well. Though to do this > >>>>> 'properly' we > >>>>> would probably end up with another typeclass "StrictFunctor" or > >>>>> something, > >>>>> and that is perhaps too much unnecessary complexity. > >>>>> > >>>>> > >>>>> Do you have an example of such a functor? > >>>>> > >>>>> -- Johan > >>>>> > >>>> > >>>> The first thing that came to mind was ZipList. Perhaps a more realistic > >>>> example would be parsing combinator or FRP libraries that are applicative > >>>> but not monadic. > >>>> > >>>> > >>>> Twan > >>>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > >> > >> > > > > _______________________________________________ > > 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From nicolas at incubaid.com Sat Nov 30 13:18:51 2013 From: nicolas at incubaid.com (Nicolas Trangez) Date: Sat, 30 Nov 2013 14:18:51 +0100 Subject: Proposal: Add a strict version of <$> for monads In-Reply-To: <20131130110506.GA4626@sniper> References: <52988669.4070706@gmail.com> <5298A9B2.9080607@gmail.com> <20131130110506.GA4626@sniper> Message-ID: On Nov 30, 2013 12:05 PM, "Roman Cheplyaka" wrote: > > No. Evaluation of your 'strictify' function will be delayed for the very > same reason that evaluation of 'f' is delayed in the first place. > > It doesn't matter what 'strictify' *does* if it's not even evaluated. Right, I see. Monad is required for the proper sequencing. Thanks! Nicolas > > * Nicolas Trangez [2013-11-30 02:11:02+0100] > > I'm without a doubt overlooking something, but couldn't this be (otoh) > > > > fmap' :: Functor f => (a -> b) -> f a -> f b > > fmap' f = fmap (strictify f) > > where > > strictify s = (($!) id) . s > > > > Nicolas > > On Nov 30, 2013 12:11 AM, "Edward Kmett" wrote: > > > > > Figure out how to write one using either of those APIs, and I'll be quite > > > impressed. =) > > > > > > I personally use this quite often when working in a monad, in lieu of > > > `return $!` games. > > > > > > The argument for implementing a version of it in terms of Monad and not > > > some new class off to the side of the class hierarchy that Monad doesn't > > > subclass is that, frankly, if such a thing existed, I'd still have to use > > > this combinator anyways when working with a transformer stack, etc. and > > > would derive little benefit. > > > > > > -Edward > > > > > > > > > On Fri, Nov 29, 2013 at 12:03 PM, Carter Schonwald < > > > carter.schonwald at gmail.com> wrote: > > > > > >> could someone explain to me why this <$!> would be for monads rather > > >> being more generally also for functors or applicatives? > > >> > > >> > > >> On Fri, Nov 29, 2013 at 10:35 AM, Johan Tibell < johan.tibell at gmail.com>wrote: > > >> > > >>> I'm trying to figure out whether this is a property of the functor > > >>> itself. I guess it is, but at the same time it seems somewhat orthogonal > > >>> whether to `seq` some value`. > > >>> > > >>> > > >>> On Fri, Nov 29, 2013 at 3:50 PM, Twan van Laarhoven < twanvl at gmail.com>wrote: > > >>> > > >>>> On 29/11/13 12:23, Johan Tibell wrote: > > >>>> > > >>>>> On Fri, Nov 29, 2013 at 1:19 PM, Twan van Laarhoven < twanvl at gmail.com > > >>>>> > wrote: > > >>>>> > > >>>>> I don't like that this function is implemented for Monads, I think > > >>>>> that it > > >>>>> makes sense for some other functors as well. Though to do this > > >>>>> 'properly' we > > >>>>> would probably end up with another typeclass "StrictFunctor" or > > >>>>> something, > > >>>>> and that is perhaps too much unnecessary complexity. > > >>>>> > > >>>>> > > >>>>> Do you have an example of such a functor? > > >>>>> > > >>>>> -- Johan > > >>>>> > > >>>> > > >>>> The first thing that came to mind was ZipList. Perhaps a more realistic > > >>>> example would be parsing combinator or FRP libraries that are applicative > > >>>> but not monadic. > > >>>> > > >>>> > > >>>> Twan > > >>>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> 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 > > >> > > >> > > > > > > _______________________________________________ > > > 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 hvr at gnu.org Sat Nov 30 18:41:42 2013 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Sat, 30 Nov 2013 19:41:42 +0100 Subject: Proposal: Add a strict version of <$> for monads In-Reply-To: <20131130110506.GA4626@sniper> (Roman Cheplyaka's message of "Sat, 30 Nov 2013 13:05:06 +0200") References: <52988669.4070706@gmail.com> <5298A9B2.9080607@gmail.com> <20131130110506.GA4626@sniper> Message-ID: <878uw5d95l.fsf@gnu.org> On 2013-11-30 at 12:05:06 +0100, Roman Cheplyaka wrote: > * Nicolas Trangez [2013-11-30 02:11:02+0100] >> I'm without a doubt overlooking something, but couldn't this be (otoh) >> >> fmap' :: Functor f => (a -> b) -> f a -> f b >> fmap' f = fmap (strictify f) >> where >> strictify s = (($!) id) . s > No. Evaluation of your 'strictify' function will be delayed for the very > same reason that evaluation of 'f' is delayed in the first place. > > It doesn't matter what 'strictify' *does* if it's not even evaluated. jfyi, if compiled with ghc -O2 -dsuppress-all -dsuppress-uniques -ddump-simpl it can be seen that fmap' is really almost the same as a plain fmap, except for an left-over eta-expansion which ghc doesn't optimize away: fmap' = \ @ a @ b @ f $dFunctor f1 -> fmap $dFunctor (\ x -> f1 x)