- Libraries - Haskell.org

[Haskell] Core libraries committee seeking self-nominations
by Edward Kmett 03 Jun '14

03 Jun '14

The first year of the Haskell Core Libraries Committee <http://www.haskell.org/haskellwiki/Core_Libraries_Committee> is winding down, and we are seeking self-nominations to replace two outgoing committee members. Doug Beardsley and Brent Yorgey have offered to be the first two members of the committee to have their slots come up for renewal. To nominate yourself, please send an email to core-libraries-committee(a)haskell.org by June 30th and include any information that you think will help us reach a decision. The core libraries committee acts as the collective maintainer of many packages that glue together the Haskell Platform, but which otherwise do not have an individual maintainer. See Library Submissions <http://www.haskell.org/haskellwiki/Library_submissions> for more details about which packages fall to the committee for maintenance. As we are now talking on more of the implementation effort for the Applicative-Monad Proposal, bringing Foldable and Traversable into Prelude, performing active maintenance on vector, etc., you should be forewarned that these are becoming increasingly active positions now that GHC 7.8 has shipped and we are ramping up for more active participation in the GHC release process. Regards, Edward Kmett Haskell Core Libraries Committee Chair

1 0

Proposal: instance TestEquality IORef
by Ashley Yakeley 01 Jun '14

01 Jun '14

The base package includes the class Data.Type.Equality.TestEquality, for types from which type equality can be deduced from values. Given values ra rb of types "IORef a" and "IORef b", if they are the same value (i.e. ra == unsafeCoerce rb), then one can deduce "a ~ b". Therefore, IORef can be made an instance of TestEquality. The same is true for various other reference types. I propose these instances in base: instance TestEquality IORef instance TestEquality (STRef s) -- Ashley Yakeley

2 1

Error installing gtk3
by Francesco Ariis 31 May '14

31 May '14

Hello everyone, I am trying to install gtk3 on Debian Wheezy (i386), without much success (see attached file for detailed error). I tried running |cabal update|, deleting ~/.ghc/<environment>/package.conf.d/glib* ~/.ghc/<environment>/package.conf.d/gtk* ~/.ghc/<environment>/package.conf.d/webkit* ~/.cabal/bin/gtk* ~/.cabal/packages/hackage.haskell.org/glib* ~/.cabal/packages/hackage.haskell.org/gtk* ~/.cabal/packages/hackage.haskell.org/webkit* and then recompiling, but I am still stuck with the same error. Any idea on where to look / what to do to fix this? Thanks -F

2 2

Gearing up (again) for the next release: 2014.2.0.0
by Mark Lentczner 30 May '14

30 May '14

SO, In anticipation of releasing a HP shortly (1 month?) after GHC 7.8... I'd like to get going on nailing down package versions. I've been working intently on the new Haskell Platform build process (see the new-build branch<https://github.com/haskell/haskell-platform/tree/new-build>), and have been building platforms against the release. Here is the description of versions I'm working with: [ incGHC "7.8" , incGHCLib "array" "0.5.0.0" , incGHCLib "base" "4.7.0.0" , incGHCLib "bytestring" "0.10.4.0" , incGHCLib "Cabal" "1.18.1.3" , incGHCLib "containers" "0.5.4.0" , incGHCLib "deepseq" "1.3.0.2" , incGHCLib "directory" "1.2.0.2" , incGHCLib "filepath" "1.3.0.2" , incGHCLib "haskell2010" "1.1.1.1" , incGHCLib "haskell98" "2.0.0.3" , incGHCLib "hpc" "0.6.0.1" , incGHCLib "old-locale" "1.0.0.6" , incGHCLib "old-time" "1.1.0.2" , incGHCLib "pretty" "1.1.1.1" , incGHCLib "process" "1.2.0.0" , incGHCLib "template-haskell" "2.9.0.0" , incGHCLib "time" "1.4.1" , incGHCLib "transformers" "0.3.0.0" , notWindows $ incGHCLib "unix" "2.7.0.1" , onlyWindows $ incGHCLib "Win32" "2.3.0.1" , incLib "async" "2.0.1.5" , incLib "attoparsec" "0.10.4.0" , incLib "case-insensitive" "1.1.0.3" , incLib "cgi" "3001.1.7.5" , incLib "fgl" "5.4.2.4" , incLib "GLUT" "2.5.0.2" , incLib "GLURaw" "1.4.0.0" , incLib "haskell-src" "1.0.1.5" , incLib "hashable" "1.2.1.0" , incLib "html" "1.0.1.2" , incLib "HTTP" "4000.2.10" , incLib "HUnit" "1.2.5.2" , incLib "mtl" "2.1.2" , incLib "network" "2.4.2.2" , incLib "OpenGL" "2.9.1.0" , incLib "OpenGLRaw" "1.4.0.0" , incLib "parallel" "3.2.0.4" , incLib "parsec" "3.1.5" , incLib "primitive" "0.5.2.1" , incLib "QuickCheck" "2.6" , incLib "random" "1.0.1.1" , incLib "regex-base" "0.93.2" , incLib "regex-compat" "0.95.1" , incLib "regex-posix" "0.95.2" , incLib "split" "0.2.2" , incLib "stm" "2.4.2" , incLib "syb" "0.4.1" , incLib "text" "1.1.0.0" , incLib "unordered-containers" "0.2.3.3" , incLib "vector" "0.10.9.1" , incLib "xhtml" "3000.2.1" , incLib "zlib" "0.5.4.1" , incTool "cabal-install" "1.18.0.3" , incTool "alex" "3.1.2" , incTool "happy" "1.19.2" , incTool "hscolour" "1.20.3" , incTool "haddock" "2.14.0" ] However, there are some issues to contend with: *Haddock* - is there any reason not to use the version built and distributed with GHC 7.8? *Shipped w/GHC* - GHC 7.8 ships with several more packages than we include in the platform. I want to review how these are handled: *possibly include in platform* - binary-0.7.1.0 - ghc-prim-0.3.1.0 - hoopl-3.10.0.0 *shouldn't include in platform* - bin-package-db-0.0.0.0 - integer-gmp-0.5.1.0 - rts-1.0 *shipped with GHC, but not registered in pkg-db, yet possible useful to include in platform:* - haskeline-0.7.1.2 - terminfo-0.4.0.0 - xhtml-3000.2.1 -- already in platform, but HP re-builds it... seems silly? *cgi* - no longer builds, and we've been unwilling to bring it forward because it pulls in MonadCatchIO-mtl *hscolour* - never approved as part of platform, but we use it to generate the haddock in both GHC and the Platform - shouldn't we just include it? *New packages:* Last time we had a bunch we wanted... but timing, especially vis-a-vis 7.8 and the new Builder classes, caused us to delay them. Shall we include: aeson dlist (needed by aeson, which version?) scientific (needed by aeson - or get aeson to subsume that code?) *anything else? now's the time to propose!* - Mark

29 135

data-default WAS: [containers] Proposal: Change to the Data.Map Monoid
by Michael Snoyman 29 May '14

29 May '14

Starting a new thread to continuing discussing this (I should have done so in the first place). Here's the problem: a class like Default is most useful if everyone's using the same class. The reason is that multiple libraries are all free to reexport the `def` symbol, and they'll all refer to the same identifier. If multiple `def`s exist, then this doesn't work, you need to be careful about *which* `def` you're using, and you may as well just export a default value under its own unique name. I think data-default-generics is overall an improvement on data-default, but the very nature of a fork here makes both packages less useful. I'd much rather that data-default simply merged in data-default-generics. On Wed, May 21, 2014 at 6:12 PM, João Cristóvão <jmacristovao(a)gmail.com>wrote: > Sorry for continuing the off-topic, and for promoting a package of mine: > > If you only need the class definition, > http://hackage.haskell.org/package/data-default-class is a better choice, > with no dependencies. > > If you prefer a single package with all the dependencies (and with > additional generics support), my own fork might be useful: > http://hackage.haskell.org/package/data-default-generics > > Although I mirrored the original package dependencies, many of which might > actually be unnecessary... (given the generics implementation). > > Cheers > > > 2014-05-21 15:59 GMT+01:00 Michael Snoyman <michael(a)snoyman.com>: > > At the risk of veering terribly off-topic... the splitting of data-default >> into all of those packages caused me a bunch of dependency headaches, most >> of which I still don't fully comprehend. I miss the good ol' days of a >> single package. >> >> >> On Wed, May 21, 2014 at 5:53 PM, Edward Kmett <ekmett(a)gmail.com> wrote: >> >>> I find myself rather hesitant to recommend that instantiation of the >>> idea ever since it exploded into a half-dozen packages full of orphan >>> instances, but yes. >>> >>> -Edward >>> >>> >>> On Wed, May 21, 2014 at 6:38 AM, Herbert Valerio Riedel <hvr(a)gnu.org>wrote: >>> >>>> On 2014-05-21 at 00:23:44 +0200, Andreas Abel wrote: >>>> >>> _Lots_ of users initialize empty maps with mempty >>>> > >>>> > Well, this is another issue, empty should be overloaded via >>>> > >>>> > class Empty a where >>>> > empty :: a >>>> >>>> Btw, isn't this what >>>> >>>> http://hackage.haskell.org/package/data-default >>>> >>>> provides? >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries(a)haskell.org >>>> http://www.haskell.org/mailman/listinfo/libraries >>>> >>> >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/libraries >>> >>> >> >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> >> >

14 28

Re: Add laws to Alternative
by Twan van Laarhoven 28 May '14

28 May '14

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 <twanvl(a)gmail.com > <mailto:twanvl@gmail.com>> 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… > <http://hackage.haskell.org/package/base-4.6.0.1/docs/Control-Monad.html#t:M…> > [2] http://www.haskell.org/__haskellwiki/MonadPlus > <http://www.haskell.org/haskellwiki/MonadPlus> > _________________________________________________ > Libraries mailing list > Libraries(a)haskell.org <mailto:Libraries@haskell.org> > http://www.haskell.org/__mailman/listinfo/libraries > <http://www.haskell.org/mailman/listinfo/libraries> > >

9 11

Fwd: Re: Gearing up (again) for the next release: 2014.2.0.0
by Christian Maeder 28 May '14

28 May '14

forwarded to libraries(a)haskell.org (as I'm not on haskell-platform(a)projects.haskell.org) -------- Original-Nachricht -------- Betreff: Re: Gearing up (again) for the next release: 2014.2.0.0 Datum: Wed, 28 May 2014 15:55:18 +0200 Von: Christian Maeder <Christian.Maeder(a)dfki.de> An: Mark Lentczner <mark.lentczner(a)gmail.com> Kopie (CC): haskell-platform(a)projects.haskell.org <haskell-platform(a)projects.haskell.org>, Johan Tibell <johan.tibell(a)gmail.com>, Ganesh Sittampalam <ganesh(a)earth.li> Am 28.05.2014 07:05, schrieb Mark Lentczner: > *Please check over the current state of the packages and versions for > 2014.1: > * > > https://github.com/haskell/haskell-platform/blob/new-build/hptool/src/Relea… At least the packages network and HTTP have newer versions on hackage. Cheers Christian

1 0

Proposal: derive Typeable for Data.Monoid types
by Roman Cheplyaka 27 May '14

27 May '14

I was surprised to find out that wrappers like Last do not have Typeable instances. Let's add them. Roman

5 6

Re: [containers] Proposal: Change to the Data.Map Monoid
by Alec 21 May '14

21 May '14

On Wed, May 21, 2014 at 12:11 PM, David Thomas wrote: > For what it's worth, I'd find Semigroup v => Monoid (Map k v) both > more useful and less surprising There is something somewhat surprising about the (Monoid v) => Monoid (Map k v) instance never using v's mempty. > ...than the current unqualified monoid instance for all maps Also (and I may have missed this argument being made already, apologies if so): It would be weird if Data.Map had the new monoid behavior but Data.IntMap didn't. And then of course, it would be weird if Data.Map had it but Data.HashMap didn't. Data.Set should probably remain the same, though it might feel a bit weird that Map k () wasn't isomorphic to Set k. Anyway, the real upshot is that unordered-containers would probably need to move along with containers, and that in addition to the social problem of moving the community in general, there would be additional gnashing of teeth from implementors of other map types who have followed the convention laid down in the "signature" for Data.Map. -A

2 1

Is it an error to call hGetLine on a non-blocking Handle?
by Alain O'Dea 19 May '14

19 May '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi folks: I could really use an expert eye on this. I'm trying to get to the bottom of a very tenacious bug in the GHC Builder. The details of how this happens are documented separately for reference: https://gist.github.com/AlainODea/dc841046524cd7833da8 The Handles involved are returned by System.Process.runInteractiveProcess. They are non-blocking at the Illumos kernel level. It appears that maybeFillReadBuffer (called by hGetLine under the hood) treats EAGAIN as an error: http://hackage.haskell.org/package/base-4.7.0.0/docs/src/GHC-IO-Handle-Text… Is it expected that runInteractiveProcess would return non-blocking Handles for stdout and stderr? Is it an error to call hGetLine on a non-blocking Handle? Thanks, Alain -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTaG1jAAoJEP0rIXJNjNSAxpwH/immeV301FEZx9o6Q0ODCuqK AUBnDHcjS9VBqhJ7XnuwkWXi83qNJhoi9P4RjamL3EGnScHVfa1mnpkX5T1IWCb4 S4lWxICbVH4tmFYOwHmElzi8vzBvgmsCueiU5uMJc66dteR4U2e9FHb9Vaurg222 dDwfIYu7mIEb/Fld4dqN+qFp9ZbVPxjBASVPlIDpZFY95+0hMq/s331B5T6zi/ZZ o63pYR2xkIScIlocEYaYJT67OssYxHScu6F/dOu4F4dllV013cP0x6/6ov4KCpBi fqM5WRid1UyTtCco2dXg7eRkzQxEMoVL0TpEQbDn/iWKJS99+rG3YSt5JYDbhTY= =xtDH -----END PGP SIGNATURE-----

3 4