April 2014 - Libraries

Proposal: add ifM and whenM to Control.Monad
by Mario Pastorelli 27 Apr '14

27 Apr '14

I would like to propose the addition of two new combinators to Control.Monad: ifM :: (Monad m) => m Bool -> m a -> m a -> m a whenM :: (Monad m) => m Bool -> m () -> m () The reason is that when you work in a `Monad m` the first argument of `if` and `when` is often a `m Bool` and not a `Bool`. In those cases, you have to write: monadicOperationReturningBool >>= \b -> when b doAnotherMonadicOperation or monadicOperationReturningBool >>= flip when doAnotherMonadicOperation to accomplish what you want to do. If you use the do-notation this is less terrible but you still need to assign a name to the boolean value. Take for example: f = do dirDoesntExist <- not <$> doesDirectoryExist path when dirDoesntExist $ do putStrLn $ "Creating directory " ++ path createDirectory path in this snippet, dirDoesntExist is completely useless and its only purpose it to be used in the next expression. With the new combinators you could write: f = whenM (not <$> doesDirectoryExists path) $ do putStrLn $ "Creating directory " ++ path createDirectory path Many libraries on hackage already include these functions (I often use Control.Conditional). For a list see http://holumbus.fh-wedel.de/hayoo/hayoo.html?query=whenM&start=0.

24 60

Proposal: Add log1p and expm1 to GHC.Float.Floating
by Edward Kmett 25 Apr '14

25 Apr '14

log1p and expm1 are C standard library functions that are important for work with exponentials and logarithms. I propose adding them to the Floating class where it is defined in GHC.Float . We do not have to export these from Prelude. My knee-jerk reaction is that we probably shouldn't. The names are kind of awful, but are standard across the rest of the industry. We already have a precedent of not exporting clutter in the classes in the existing Data.Functor containing (<$), but it not currently coming into scope from the Prelude. They are critical for any reasonably precise work with logarithms of values near 1, and of exponentials for small values of *x*, and it is somewhat embarrassing explaining to someone coming from the outside with a numerical background whom expects to find them to exist why we don't have them. These arise all over the place in any work on probabilities in log-scale. Backgrounder: Consider >>> exp 0.0000003 1.000000300000045 As the argument x get small, this gets very close to 1 + x. However, that leading 1 means you've consumed most of the precision of the floating point number you are using. 6 decimal places is ~18 bits of your significand that are just gone because of bad math. If we subtract out the leading term after it has destroyed all of our precision it is too late. >>> exp 0.0000003 - 1 3.0000004502817035e-7 has lost a lot of precision relative to: >>> expm1 0.0000003 3.000000450000045e-7 Now every decimal place we get closer to 0 doesn't destroy a decimal place of precision! Similar issues arise with logs of probabilities near 1. If you are forced to use log, as your probability gets closer to 1 from below you throw away most of your accuracy just by encoding the argument to the function with the same kind of error rate. Here is straw man documentation ripped from my log-domain package that is probably way too technical, but serves as a starting point for discussion. class ... => Floating a where -- | The Taylor series for @'exp' x@ is given by -- -- @ -- 'exp' x = 1 + x + x^2/2! + x^3/3! ... -- @ -- -- When @x@ is small, the leading @1@ consumes virtually all of the available precision, -- because subsequent terms are very small. -- -- This computes: -- -- @ -- exp x - 1 = x + x^2/2! + .. -- @ -- -- For many types can afford you a great deal of additional precision if you move -- things around algebraically to provide the 1 by other means. expm1 :: Floating a => a -> a expm1 x = exp x - 1 -- | Computes @log(1 + x)@ -- -- This is away from 0 so the Taylor series is defined, but it also provides an inverse to 'expm1'. -- -- This can provide much more accurate answers for logarithms of numbers close to 1 (x near 0). -- -- @ -- log1p (expm1 x) = log (1 + exp x - 1) = log (exp x) -- @ log1p :: Floating a => a -> a log1p x = log (1 + x) They can be given definitions in terms of the standard C library functions for the CFloat, CDouble, Float and Double, either by foreign import or adding a pair of foreign prims. Finally, here is a robust implementation for Data.Complex from the same package that properly deals with the subtleties involved in not losing precision. expm1 x@(a :+ b) | a*a + b*b < 1, u <- expm1 a, v <- sin (b/2), w <- -2*v*v = (u*w+u+w) :+ (u+1)*sin b | otherwise = exp x - 1 {-# INLINE expm1 #-} log1p x@(a :+ b) | abs a < 0.5 && abs b < 0.5, u <- 2*a+a*a+b*b = log1p (u/(1+sqrt (u+1))) :+ atan2 (1 + a) b | otherwise = log (1 + x) {-# INLINE log1p #-} Discussion Period: 2 weeks -Edward Kmett

18 58

rfc: Additions to Data.Either (take 2)
by João Cristóvão 24 Apr '14

24 Apr '14

Hello, So following Carter Schonwald suggestion of creating a new thread, but not literally, since the amount of combinations would be huge, here is my own humble attempt to gather all hypothesis discussed into separate proposals, for your voting pleasure. (Some are mutually exclusive, some are not) Proposal 0: ---------------- Do nothing Proposal 1: ---------------- Add no new code, but document Data.Either to mention how to use `left` and (+++) from Control.Arrow Proposal 2: ---------------- Document Control.Arrow to exemplify the (->) instance usage. Proposal 3: ---------------- Implement mapLeft in Data.Either 3a) ... as (a -> b) -> Either a c -> Either b c (so that is easy to follow) 3b) ... as Control.Arrow.left 3c) ... and also redefine the -> instance of Control.Arrow.left as mapLeft Proposal 4: ---------------- Implement mapBoth in Data.Either 4a) ... as (a -> b) -> (c -> d) -> Either a c -> Either b d (so that is easy to follow) 4b) ... as Control.Arrow.(+++) 4c) ... and also redefine the -> instance of Control.Arrow.(+++) as mapBoth Proposal 5: ---------------- == Proposal 4, using the mapEither name instead. Proposal 6: ---------------- Implement mapRight in Data.Either 6a) ... as (b -> c) -> Either a b -> Either a c 6b) ... as fmap Proposal 7: ---------------- Don't implement mapRight, but include documentation in Data.Either stating that it is just fmap. Proposal 8: ---------------- Bring bifunctors to base.

10 10

Re: Libraries Digest, Vol 128, Issue 72
by Benno Fünfstück 22 Apr '14

22 Apr '14

> > On 2014-04-21 at 22:01:34 +0200, Jo?o Crist?v?o wrote: > > Proposal 1: > > ---------------- > > Add no new code, but document Data.Either to mention how to use `left` > and > > (+++) from Control.Arrow > +1, I'd also like if Data.Either reexported those functions. Then, the documentation could just give some more specific type signatures that show how to use them (like the lens library does in many cases). > > Proposal 2: > > ---------------- > > Document Control.Arrow to exemplify the (->) instance usage. > +1 > Proposal 3: > > ---------------- > > > > Implement mapLeft in Data.Either > > > > 3a) ... as (a -> b) -> Either a c -> Either b c (so that is easy to > follow) > > 3b) ... as Control.Arrow.left > > 3c) ... and also redefine the -> instance of Control.Arrow.left as > mapLeft > > -1, just export left from Data.Either and give it a more specific type signature in the documentation. > > > Proposal 4: > > ---------------- > > > > Implement mapBoth in Data.Either > > > > 4a) ... as (a -> b) -> (c -> d) -> Either a c -> Either b d (so that is > > easy to follow) > > 4b) ... as Control.Arrow.(+++) > > 4c) ... and also redefine the -> instance of Control.Arrow.(+++) as > mapBoth > > -1, same reason as 3 (using +++) > > Proposal 5: > > ---------------- > > > > == Proposal 4, using the mapEither name instead. > > -1 > > > Proposal 6: > > ---------------- > > > > Implement mapRight in Data.Either > > > > 6a) ... as (b -> c) -> Either a b -> Either a c > > 6b) ... as fmap > > -1, fmap is already in Prelude and well-known > > > Proposal 7: > > ---------------- > > > > Don't implement mapRight, but include documentation in Data.Either > stating > > that it is just fmap. > > +1 > > > Proposal 8: > > ---------------- > > > > Bring bifunctors to base. > +1

1 0

Counter proposal: Do not include whenM and ifM
by Tom Ellis 22 Apr '14

22 Apr '14

(Since Carter asked for new proposals to be started in a separate thread I am reposting the contents of an earlier message with additions) My (counter) proposal is that 'whenM' and 'ifM' *not* be added anywhere (under any names) because there is a completely generic alternative to these adhoc additions that warrants further investigation. The executive summary is that instead of introducing another function 'unlessM' to be used like this unlessM doesDirectoryExist path $ do putStrLn $ "Creating directory " ++ path createDirectory path we just use the existing 'unless' and a new generic combinator (<*>|) like this unless <$> doesDirectoryExist path <*>| pure (do putStrLn $ "Creating directory " ++ path createDirectory path) I have been reading the discussion about 'whenM' and 'ifM' wondering where it is going to end. Presumably we will also have 'unlessM'. Then 'guardM' becomes a reasonable candidate, and indeed 'libraryFunctionM' for any 'libraryFunction' that happens to have a monadic return type and non-monadic argument. It is as if everyone is discussing how many 'liftAn' we should provide when (<$>) and (<*>) already do the job generically. The generic alternative that I believe warrants further investigation is to add an operator called, for example, (<*>|) to be read as "apply and done". All these specific questions about whether a function should take a monadic argument or not are solved generically by (<$>), (<*>) and (<*>|) as demonstrated below. It is no more complex than just using the Applicative combinators (<$>) and (<*>) we know and love. It seems the discussion about 'mif' vs 'ifM' can be completely finessed. Those functions are no more convenient than (<*>|) syntax. There may be an even better syntax than the one I propose here but I think it's actually pretty good as it is. I would appreciate some feedback on this. Tom import Control.Monad import Control.Applicative -- vv For the example! import System.Directory -- The operator, read as "apply and done", for applying a monadic -- argument and completing the chain of applications. infixl 4 <*>| (<*>|) :: Monad m => m (a -> m b) -> m a -> m b f <*>| x = join (f `ap` x) -- Suppose we have an 'f' that takes some monadic arguments and some pure -- arguments f :: Monad m => Int -> Bool -> m Char -> Float -> m Double -> m Integer f = undefined -- Then we just use Applicative combinators plus (<*>|) to apply monadic -- arguments fM :: (Monad m, Applicative m) => m Int -> m Bool -> m Char -> m Float -> m Double -> m Integer fM a b c d e = f <$> a <*> b <*> pure c <*> d <*>| pure e -- Here's another example f' :: Monad m => Int -> Bool -> m Char -> Float -> m Double -> String -> m Integer f' = undefined -- Not all of the arguments to the result need to be monadic. We can keep -- some pure if we like. f'M :: (Monad m, Applicative m) => m Int -> Bool -> m Char -> Float -> m Double -> m String -> m Integer f'M a b c d e f = f' <$> a <*> pure b <*> pure c <*> pure d <*> pure e <*>| f -- Implementing whenM, unlessM and ifM is easy. whenM :: (Monad m, Applicative m) => m Bool -> m () -> m () whenM cond action = when <$> cond <*>| pure action unlessM :: (Monad m, Applicative m) => m Bool -> m () -> m () unlessM cond action = unless <$> cond <*>| pure action if_ :: Bool -> a -> a -> a if_ cond then_ else_ = if cond then then_ else else_ ifM :: (Monad m, Applicative m) => m Bool -> m () -> m () -> m () ifM cond then_ else_ = if_ <$> cond <*> pure then_ <*>| pure else_ -- But the point is that you don't actually need whenM, unlessM or ifM, -- since it's easy to feed arguments to when, unless and if_ directly. path = undefined usingUnless = unless <$> doesDirectoryExist path <*>| pure (do putStrLn $ "Creating directory " ++ path createDirectory path)

6 6

RE: [core libraries] Re: Tightening up on inferred type signatures
by Niklas Haas 22 Apr '14

22 Apr '14

On Tue, 22 Apr 2014 06:44:26 +0000, Simon Peyton Jones <simonpj(a)microsoft.com> wrote: > | Independent of language extensions, what about types and classes whose > | names are not in scope. Is there an implicit "... if you import all > | the relevant symbols" and the end of the rule? > > Good point. I'm honestly unsure how far to push this one! (It'd be relatively easy to check whether they were in scope and complain if not, but ...) > > Simon My stance on this is that, without the appropriate names in scope, you are actually specifying a different type signature to the one that GHC inferred (or none at all, if the names are unbound) - so this rule doesn't cover. The ruling that it would be valid, had you specified the precise signature GHC inferred is not broken, because you're actually specifying a different signature. Meanwhile, in the case of FlexibleContexts etc. you are actually specifying precisely the signature that GHC infers, but it's getting rejected due to other rulings.

1 0

rfc: include bimap into Data.Either
by Tobias Florek 21 Apr '14

21 Apr '14

hi, i propose to include the following functions into Data.Either. mapLeft :: (a->b) -> Either a c -> Either b c mapLeft f = bimap f id bimap :: (a -> b) -> (c -> d) -> Either a c -> Either b d bimap f g = either (Left . f) (Right . g) bimap and mapLeft already exists in edward kmett's either library (and in categories-extras and in gabriel gonzales' errors), but imo they are very useful by itself to warrant an inclusion in base. given bimap, mapLeft might not cross the fairbairn threshold though. note: i don't propose exporting them from Prelude. discussion period: 2 weeks cheers, tobias florek

13 20

installing webkitgtk3: webkitgtk-3.0 version >=1.8 not found
by Blue Glacier 18 Apr '14

18 Apr '14

Hello, $ cabal install webkitgtk3 Resolving dependencies... [1 of 2] Compiling SetupWrapper ( /var/folders/27/1y1549hn7pqfvvd0zv7znvlm0000gn/T/webkitgtk3-0.12.6.1-5804/webkitgtk3-0.12.6.1/SetupWrapper.hs, /var/folders/27/1y1549hn7pqfvvd0zv7znvlm0000gn/T/webkitgtk3-0.12.6.1-5804/webkitgtk3-0.12.6.1/dist/setup/SetupWrapper.o ) [2 of 2] Compiling Main ( /var/folders/27/1y1549hn7pqfvvd0zv7znvlm0000gn/T/webkitgtk3-0.12.6.1-5804/webkitgtk3-0.12.6.1/Setup.hs, /var/folders/27/1y1549hn7pqfvvd0zv7znvlm0000gn/T/webkitgtk3-0.12.6.1-5804/webkitgtk3-0.12.6.1/dist/setup/Main.o ) Linking /var/folders/27/1y1549hn7pqfvvd0zv7znvlm0000gn/T/webkitgtk3-0.12.6.1-5804/webkitgtk3-0.12.6.1/dist/setup/setup ... [1 of 2] Compiling Gtk2HsSetup ( Gtk2HsSetup.hs, dist/setup-wrapper/Gtk2HsSetup.o ) [2 of 2] Compiling Main ( SetupMain.hs, dist/setup-wrapper/Main.o ) Linking dist/setup-wrapper/setup ... Configuring webkitgtk3-0.12.6.1... setup: The pkg-config package webkitgtk-3.0 version >=1.8 is required but it could not be found. Failed to install webkitgtk3-0.12.6.1 cabal: Error: some packages failed to install: webkitgtk3-0.12.6.1 failed during the configure step. The exception was: ExitFailure 1 What's going on there?

4 5

Requesting permission to update geniplate
by Andreas Abel 17 Apr '14

17 Apr '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Library Tsars, I am requesting permission to upload geniplate-0.6.0.4 to hackage which bumps the upper bound for the template-haskell dependency to allow 2.9.*. geniplate is necessary to compile Agda on ghc-7.8, and Lennart Augustsson, the author and maintainer of geniplate has been unresponsive to our requests for several weeks. I am AndreasAbel on hackage. Cheers, Andreas - -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel(a)gu.se http://www2.tcs.ifi.lmu.de/~abel/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNOr2YACgkQPMHaDxpUpLPZtACfTcdsNqnFHK5DTDtuBqGh72kv C8EAoL6+GCD20SEB6YGrzIFXXQs9L5mT =BJIO -----END PGP SIGNATURE-----

2 2

Cabal-install binaries
by harry 10 Apr '14

10 Apr '14

http://www.haskell.org/cabal/release/ only goes up to 1.18.0.2, and only has binaries for Windows. Are there any plans for 1.18.0.3 and Linux binaries? -- View this message in context: http://haskell.1045720.n5.nabble.com/Cabal-install-binaries-tp5747383.html Sent from the Haskell - Libraries mailing list archive at Nabble.com.

1 0