- Libraries - Haskell.org

System.Directory.removeDirectoryRecursive and symlinks
by Gracjan Polak 10 Jun '14

10 Jun '14

Hi all, A crime scene: Prelude System.Directory> :!mkdir a-directory Prelude System.Directory> :!touch a-directory/a-file.txt Prelude System.Directory> :!ln -s "a-directory" "a-symlink-to-a-directory" Prelude System.Directory> :!ls a-directory a-file.txt Prelude System.Directory> :!ls a-symlink-to-a-directory a-file.txt Prelude System.Directory> removeDirectoryRecursive "a-symlink-to-a-directory" *** Exception: a-symlink-to-a-directory: removeDirectory: inappropriate type (Not a directory) Prelude System.Directory> :!ls a-symlink-to-a-directory Prelude System.Directory> :!ls a-directory Prelude System.Directory> :!ls -a a-directory . .. Prelude System.Directory> :!ls -a a-symlink-to-a-directory . .. Prelude System.Directory> removeDirectoryRecursive is removing all contents *of the directory linked* but is unable to remove the symlink itself. This behavior is surprizing if not dangerous. I understand that this mimics behavior of unlink/rmdir and DeleteFile/RemoveDirectory. but let me quote relevant manuals: man rm: The rm utility removes symbolic links, not the files referenced by the links. DeleteFile docs: If the path points to a symbolic link, the symbolic link is deleted, not the target. To delete a target, you must call CreateFile and specify FILE_FLAG_DELETE_ON_CLOSE. RemoveDirectory removes a directory junction, even if the contents of the target are not empty; the function removes directory junctions regardless of the state of the target object. Note: doesDirectoryExist and doesFileExist follow symlinks so they add more surprize to the scenario. What can we do about this? -- Gracjan

4 7

Re: Gearing up (again) for the next release: 2014.2.0.0
by Mark Lentczner 10 Jun '14

10 Jun '14

All - I've been advised that GHC 7.8.3 is imminent and fixes some important issues. No base package versions will change, except for a small bump in haddock. I plan to incorporate this into the HP as soon as they release it - and so that will be the compiler in the upcoming HP release. Any concerns?

4 5

7.8.3 for the Platform
by Austin Seipp 06 Jun '14

06 Jun '14

Hi Mark, I was planning on releasing GHC 7.8.3 very soon (in the next few days,) and I'm wondering if it is still a possible candidate for the next Haskell Platform? To be clear, there are no library updates this time around - 7.8.3 is almost 100% a pure compiler/runtime bugfix release, and some of the fixes are quite bad. https://ghc.haskell.org/trac/ghc/ticket/9078 https://ghc.haskell.org/trac/ghc/ticket/8768 https://ghc.haskell.org/trac/ghc/ticket/9148 https://ghc.haskell.org/trac/ghc/ticket/9001 The first one, #9078, would be particularly bad to let slip into the release - it affects possibly all EDSLs using mkStableName for sharing, and is very easy to trigger by allocating stable names quickly. I'd say #8768 is somewhat nasty as well. Accelerate and SBV are two examples of projects that will crash. There are currently no plans to even bump the corresponding library numbers - we didn't do so for 7.8.2, and there are no changes at all that would warrant a bump for 7.8.3. It's really a stability release more than anything and irons out several real bumps. Do let me know what you think - I'll keep this thread updated as the release gets closer if anything else goes in. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

3 2

[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 29 May '14

29 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