- Libraries - Haskell.org

ANNOUNCE: fgl-5.5.0.0
by Ivan Lazar Miljenovic 27 Apr '14

27 Apr '14

I'm pleased to announce a new version of the functional graph library: http://hackage.haskell.org/package/fgl-5.5.0.0 The main change in this version: proper Show, Read and Eq instances for both graph implementations. Previously, Data.Graph.Inductive.Tree had a pretty-printed Show output; now both it and PatriciaTree have Show and Read instances via the mkGraph function, and Eq via deriving (I'm not sure how well this will work because as I write this I realise it may not deal with multiple edges that well... I guess I'll be doing an updated version tomorrow after getting some sleep ;p). The previous Show behaviour of Tree is now available as a pretty-printing function for all DynGraph instances. The PatriciaTree implementation is now exported and used by default, because as far as I'm aware it will always perform better. Finally, the Data.Graph.Inductive.Graphviz module has been removed; if you want to visualise your fgl graph, please see my graphviz package on Hackage (cheap plug? moi?). -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

1 0

Proposal: Changes to the PVP
by Michael Snoyman 27 Apr '14

27 Apr '14

I would like to propose the following changes to the PVP. These are the same changes that I recently published on the Yesod blog[1]. For more information on the motivations behind these changes, please see that blog post. 1. The goal of the PVP needs to be clarified. Its purpose is not to ensure reproducible builds of non-published software, but rather to provide for more reliable builds of libraries on Hackage. Reproducible builds should be handled exclusively through version freezing, the only known technique to actually give the necessary guarantees. 2. Upper bounds should not be included on non-upgradeable packages, such as base and template-haskell (are there others?). Alternatively, we should establish some accepted upper bound on these packages, e.g. many people place base < 5 on their code. 3. We should be distinguishing between mostly-stable packages and unstable packages. For a package like text, if you simply import Data.Text (Text, pack, reverse), or some other sane subset, there's no need for upper bounds. (Note that this doesn't provide a hard-and-fast rule like the current PVP, but is rather a matter of discretion. Communication between library authors and users (via documentation or other means) would be vital to making this work well.) 4. For a package version A.B.C, a bump in A or B indicates some level of breaking change. As an opt-in approach, package authors are free to associated meaning to A and B beyond what the PVP requires. Libraries which use these packages are free to rely on the guarantees provided by package authors when placing upper bounds. (Note that this is very related to point (3).) Discussion period: 3 weeks. [1] http://www.yesodweb.com/blog/2014/04/proposal-changes-pvp

18 49

Upper bounds in PVP WAS: Gearing up (again) for the next release: 2014.2.0.0
by Michael Snoyman 27 Apr '14

27 Apr '14

Starting a separate subject for this response so I don't drive Mark absolutely crazy. On Wed, Apr 9, 2014 at 3:19 PM, Vincent Hanquez <tab(a)snarc.org> wrote: > On 2014-04-08 16:29, Gregory Collins wrote: > > >> >> >> Unfortunately the entire Haskell tls/crypto ecosystem doesn't obey the >> Hackage package versioning policy and until this is fixed I think that >> issue precludes it from being included in the platform. >> >> > First of, you might want to read up on the difference between the > definition of policy and rules/law. "obey" doesn't have its place here. > > Second, the tls/crypto ecosystem is following most of the PvP apart from > "3 Dependencies in Cabal". > > Third, The PvP doesn't actually *enforce* any requirements on > dependencies. I can only see CAN, SHOULD, MAY in the section 3. > On the other hand, you can find MUST in section "2 Versions numbers", and > as far I'm concerned the tls/crypto ecosystem is following each > requirements in this section. > > Reading that section myself, I have to say I agree with Vincent's interpretation. It would seem therefore that the packages under question are in fact in compliance with the requirements of the PVP, and therefore there's no blocker to including tls in the platform in the future, regardless of how you interpret the HP's statement "we follow the Haskell Package Versioning Policy". So if someone wants to object to inclusion of tls, it would have to be on technical grounds, rather than simply quoting a document. Michael

10 14

proposal to have new proposals in new threads Re: rfc: include bimap into Data.Either
by Carter Schonwald 27 Apr '14

27 Apr '14

Hey all, if you agree that new proposals should be voted on in new/distinct threads (though can certainly be hammered out before hand), please chime in. This seems to come up a lot (at least in my naive following of the list) and if a new proposal appears in a thread you've already voted on, its hard to know curretly thoughts? On Mon, Apr 21, 2014 at 7:55 AM, Alexander Berntsen <alexander(a)plaimi.net>wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 20/04/14 23:37, Carter Schonwald wrote: > > can the people with new proposals do new threads, adding ammendments > > inline to a preexisting thread makes it really hard > > > > a) to know who supports what > > b) make it visible to folks who've > > started ignoring the thread they've already voted on > +1 ;-) > > - -- > Alexander > alexander(a)plaimi.net > https://secure.plaimi.net/~alexander > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iF4EAREIAAYFAlNVB0wACgkQRtClrXBQc7UeSwEAqDC7LhAmeG2mNmSDQ9D33ulE > +WIBcp4t66nD8H519XwA/jtSYbEZ+oq2DdtXIxAWDSeNDn53XyOiZdR4vpFCPzTm > =cFB+ > -----END PGP SIGNATURE----- > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries >

4 4

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