- Libraries - Haskell.org

Num instances for Sum and Product
by Dan Burton 22 Feb '12

22 Feb '12

Data.Monoid in the base package specifies newtypes Sum and Product. It would be convenient if these newtypes had appropriate Num instances, which are trivial to write in plain Haskell: import Data.Monoid liftTy2 wrap unwrap op x y = wrap $ unwrap x `op` unwrap yliftTy wrap unwrap f = wrap . f . unwrap liftSum = liftTy Sum getSumliftSum2 = liftTy2 Sum getSum instance (Num a) => Num (Sum a) where (+) = liftSum2 (+) (-) = liftSum2 (-) (*) = liftSum2 (*) abs = liftSum abs negate = liftSum negate signum = liftSum signum fromInteger = Sum . fromInteger liftProd = liftTy Product getProductliftProd2 = liftTy2 Product getProduct instance (Num a) => Num (Product a) where (+) = liftProd2 (+) (-) = liftProd2 (-) (*) = liftProd2 (*) abs = liftProd abs negate = liftProd negate signum = liftProd signum fromInteger = Product . fromInteger Or with a few extensions (as noted by Daniel Wagner): {-# LANGUAGE StandaloneDeriving, GeneralizedNewtypeDeriving #-} import Data.Monoid deriving instance Num a => Num (Sum a)deriving instance Num a => Num (Product a) -- Dan Burton

1 0

enummapset merge into containers
by Ben Gamari 21 Feb '12

21 Feb '12

Not so long ago, it was suggested[1] that enummapset[2] might be a good candidate for merge into containers. Having found this package to be very useful in the past, I would find this quite nice. Would others find this a reasonable proposal? If so, what needs to be done to make this happen? Cheers, - Ben [1] http://blog.ezyang.com/2011/08/changes-to-intmap/comment-page-1/#comment-28… [2] http://hackage.haskell.org/package/enummapset

4 6

Fwd: New STM?
by wren ng thornton 19 Feb '12

19 Feb '12

-------- Original Message -------- Message-ID: <4F3E9E3E.3070804(a)freegeek.org> Date: Fri, 17 Feb 2012 13:36:46 -0500 To: GHC-users List <glasgow-haskell-users(a)haskell.org> Hello all, I had some patches committed to STM a while back[1], and for some reason I was expecting them in the new GHC release. Does STM only ship with the Platform? If not, then any idea when the next version of STM will be released? [1] http://hackage.haskell.org/trac/ghc/ticket/5104 http://www.haskell.org/pipermail/cvs-libraries/2011-April/012914.html -- Live well, ~wren

1 0

Proposal: Remove Control.OldException
by Ian Lynagh 19 Feb '12

19 Feb '12

Hi all, We've had Control.OldException, and the new Control.Exception, since GHC 6.10.1, and since 6.12.1 using Control.OldException has given the deprecation message Future versions of base will not support the old exceptions style. Please switch to extensible exceptions. I propose that we now remove it from base. If some people still cannot use the new Control.Exception for some reason, then it could be maintained in an old-exception package. Discussion deadline: 18 Feb 2012. Thanks Ian

8 11

generalization of maybeToList
by Jeff Shaw 15 Feb '12

15 Feb '12

I find myself using this function quite a lot. I believe it should be included in Data.Maybe. import Control.Monad maybeTo :: (MonadPlus m) => Maybe a -> m a maybeTo = maybe mzero return

5 9

RE: Changes to Typeable
by Simon Peyton-Jones 14 Feb '12

14 Feb '12

| Should there perhaps be a NewTypeable module which could then be renamed | into Typeable once it is sufficiently well established? I started with that idea, but there would be a 2-stage process: * Step 1: (when PolyTypable becomes available) People change to import Data.PolyTypeable * Step 2: (when PolyTypeable becomes Typeable) People change back to Data.Typeable I was hoping to avoid that. Notice that even if we replace Typeable immediately with the new polymorphic one, doing so has very limited impact: for users who just use "deriving Typeable" and "typeOf", that will work fine with the new thing too. But I'm sure that some "seams" would show through. It's a balance. Simon

3 2

Something's weird about System.Directory.removeDirectoryRecursive
by John Millikin 09 Feb '12

09 Feb '12

http://hackage.haskell.org/packages/archive/directory/1.1.0.1/doc/html/Syst… The documentation says that removeDirectoryRecursive follows symlinks. However, the implementation doesn't (in most cases, see below). ------------------------------------------------------------------------------------------------------------ $ mkdir test-removeDirectoryRecursive $ cd test-removeDirectoryRecursive $ mkdir a b $ touch a/a.txt b/b.txt $ ln -s $PWD/b a/ $ ln -s $PWD/b/b.txt a/ $ ls -l a total 8.2k -rw-rw-r-- 1 john john 0 2012-01-27 23:33 a.txt lrwxrwxrwx 1 john john 65 2012-01-27 23:33 b -> /home/john/test-removeDirectoryRecursive/b lrwxrwxrwx 1 john john 71 2012-01-27 23:34 b.txt -> /home/john/test-removeDirectoryRecursive/b/b.txt # OK, a/ has a normal file and two symlinks in it. Let's recursively remove a/ and see what happens. $ ghci Prelude> import System.Directory Prelude System.Directory> removeDirectoryRecursive "a" Prelude System.Directory> Leaving GHCi. $ ls -l a b ls: cannot access a: No such file or directory b: total 0 -rw-rw-r-- 1 john john 0 2012-01-27 23:33 b.txt # a/ was removed -- good! # # b/ and its contents are untouched, good, but goes against the docs ------------------------------------------------------------------------------------------------------------ Now, there is one case where this function *will* follow symlinks. However, I believe it is a bug because it produces odd behavior: ------------------------------------------------------------------------------------------------------------ $ sudo mkdir a [sudo] password for john: $ sudo ln -s $PWD/b a/ $ ls -l a b a: total 4.1k lrwxrwxrwx 1 root root 65 2012-01-27 23:38 b -> /home/john/test-removeDirectoryRecursive/b b: total 0 -rw-rw-r-- 1 john john 0 2012-01-27 23:33 b.txt # Now a/ has a symlink, which cannot be deleted, because its containing directory is read-only to the current user. $ rm a/b rm: remove symbolic link `a/b'? y rm: cannot remove `a/b': Permission denied # What happens if removeDirectoryRecursive is called now? $ ghci Prelude> import System.Directory Prelude System.Directory> removeDirectoryRecursive "a" *** Exception: a/b: removeDirectory: permission denied (Permission denied) Prelude System.Directory> Leaving GHCi. $ ls -l a b a: total 4.1k lrwxrwxrwx 1 root root 65 2012-01-27 23:38 b -> /home/john/test-removeDirectoryRecursive/b b: total 0 # a/ is untouched, but b/ has been emptied! ------------------------------------------------------------------------------------------------------------ So what is the expected behavior of this function? What should it do in the presence of symlinks? IMO, the function should be documented as *not* following symlinks, and the directory check should be changed so that it returns False for symlink-to-directory.

3 2

Re: [Haskell-cafe] The State of Testing?
by Thomas Tuegel 09 Feb '12

09 Feb '12

On Wed, Feb 8, 2012 at 4:42 AM, Christoph Breitkopf <chbreitkopf(a)googlemail.com> wrote: > Hello Thomas, > > On Wed, Feb 8, 2012 at 4:03 AM, Thomas Tuegel <ttuegel(a)gmail.com> wrote: >> >> First, as author of the test suite code, let me apologize for the >> terrible documentation. >> >> This is absolutely NOT how coverage reports are supposed to work. If >> you configure with '--enable-tests --enable-library-coverage', Cabal >> will take care of _everything_ else for you, including excluding the >> test module from the coverage report. You should not have to put any >> flag gymnastics in your .cabal file. > > > I get only "cabal: unrecognized option `--enable-library-coverage'" when > doing that. Which cabal version do I need? > Can you point me to any docs about this? I'm still using test type > exitcode-stdio-1.0, because I could not get detailed-1.0 to work. You need Cabal 1.12 for '--enable-library-coverage'. The only place it's documented is in 'cabal configure --help' (a major oversight on my part). The online docs for Cabal are only from version 1.10 anyway, so that wouldn't have helped. I'm sorry for your struggles getting the detailed type to work. It's a known issue: the detailed test interface is intentionally disabled in all the released versions because it's going to change. That's why none of the test libraries support it yet and why you weren't able to get it to work. -- Thomas Tuegel

1 0

Template Haskell: dataToExpQ and constructor mis-match
by Conal Elliott 08 Feb '12

08 Feb '12

I'm looking for a reliable way to turn values into Template Haskell expressions. I thought dataToExpQ from Language.Haskell.TH.Quote was the ticket, but it appears to produce constructors different from those produced by [| ... |], including [], (:), (), and (,). Here's an example run for (). I'm using template-haskell-2.5.0.0: GHCi, version 7.0.4: http://www.haskell.org/ghc/ :? for help Prelude> import Data.Data Prelude Data.Data> import Language.Haskell.TH Prelude Data.Data Language.Haskell.TH> :set -XTemplateHaskell Prelude Data.Data Language.Haskell.TH> import Language.Haskell.TH.Quote Prelude Data.Data Language.Haskell.TH Language.Haskell.TH.Quote> u1 <- runQ (dataToExpQ (const Nothing) ()) Prelude Data.Data Language.Haskell.TH Language.Haskell.TH.Quote> u2 <- runQ [| () |] Prelude Data.Data Language.Haskell.TH Language.Haskell.TH.Quote> u1 ConE () Prelude Data.Data Language.Haskell.TH Language.Haskell.TH.Quote> u2 ConE GHC.Unit.() Prelude Data.Data Language.Haskell.TH Language.Haskell.TH.Quote> u1 == u2 False Any suggestions? -- Conal

2 1

Re: [Haskell-cafe] The State of Testing?
by Thomas Tuegel 08 Feb '12

08 Feb '12

On Tue, Feb 7, 2012 at 3:23 PM, Austin Seipp <mad.one(a)gmail.com> wrote: > If you're writing a library, you need to compile the library with > `-fhpc`, i.e. put it in the library stanza, not the testsuite stanza, > and then you can compile the test program using your library - the > resulting 'tix' file will contain the library coverage reports. You > can link a HPC-built library into an executable not compiled with HPC > just fine. > > Normally I only compile the library under HPC mode, link it in a test, > and distribute the results from that. That way your coverage reports > don't include the test module (which may or may not be relevant.) > > I normally add a cabal flag called 'hpc' which optionally enables > coverage reports for my library, e.g. > > flag hpc > default: False > > library > ... > ... > if flag(hpc) > ghc-options: -fhpc > > Then when you want coverage reports, just say 'cabal install -fhpc > --enable-tests' and the resulting properties executable will spit out > the results when run. First, as author of the test suite code, let me apologize for the terrible documentation. This is absolutely NOT how coverage reports are supposed to work. If you configure with '--enable-tests --enable-library-coverage', Cabal will take care of _everything_ else for you, including excluding the test module from the coverage report. You should not have to put any flag gymnastics in your .cabal file. If this doesn't work for you, please let me know, because it's a bug. Thanks! -- Thomas Tuegel

2 1