January 2015 - Libraries

Proposal: merge either into transformers
by Roman Cheplyaka 03 Jan '17

03 Jan '17

I propose to add the sole module of the 'either' package[1], Control.Monad.Trans.Either, to the transformers package. It provides EitherT, a very basic and fundamental data type. The difference between EitherT and ErrorT is that the latter has an Error constraint, which is used to imlement 'fail'. Note that 'either' depends on the 'semigroupoids' and 'semigroup' packages to provide appropriate instances. The proposal is not to add those instances to 'transformers' to avoid additional dependencies. The instances can then be left in the 'either' package or moved to the 'semigroupoids' and 'semigroup' packages respectively. ('semigroupoids' already depends on 'transformers', while 'semigroups' does not). Compared to the 'either' package, Show, Read, Eq and Ord instances will be dropped to keep the code Haskell2010 (those instances require FlexibleInstances, FlexibleContexts, and UndecidableInstances). The patch is attached. [*] [*] against transformers-0.3.0.0, because the darcs version is not buildable (Control/Monad/Signatures.hs is not in the repository). Roman

22 72

Proposal: add liftA4 and liftA5 to match liftM4 and liftM5
by David Feuer 14 Jul '16

14 Jul '16

Since Applicative is supposed to be important now, I figure we should get these in.

12 33

[containers] Proposal: Change to the Data.Map Monoid
by Nick Partridge 10 Oct '15

10 Oct '15

Hi, Currently the Monoid instance for Data.Map is implemented using union/unions, which are left biased. On key collision, it discards values from the right hand side of `mappend` - https://github.com/ghc/packages-containers/blob/bae098fb0a3994bc2b0ec331300… If you compare this with the Monoid for Maybe, it's like we're defaulting to First as the monoid instance for maps. A more useful instance, however very much a breaking change, would be to make the instance depend on a Monoid (or better yet, a Semigroup) for the values in the map: instance Monoid v => Monoid (Map k v) where mappend = unionWith mappend This lets us build up maps with values in a useful Monoid, and mappend them with gusto. Thoughts? - Nick Partridge Discussion period: 2 weeks.

15 22

Generalize filterM to Applicative
by David Feuer 25 Mar '15

25 Mar '15

Currently, filterM :: (Monad m) => (a -> m Bool) -> [a] -> m [a] filterM p = foldr go (return []) where go x r = do flg <- p x ys <- r return (if flg then x:ys else ys) We could change this to filterM :: (Applicative f) => (a -> f Bool) -> [a] -> f [a] filterM p = foldr go (pure []) where go x r = f <$> p x <*> r where f flg ys = if flg then x:ys else ys

7 12

Drastic Prelude changes imminent
by Augustsson, Lennart 11 Feb '15

11 Feb '15

The next version (7.10) of GHC is slated to have a drastically changed Prelude. This message is very late in the release process, but I would urge caution before changing. The changes are (aptly) named the Burning Bridges Proposal (BBP). Even though the work has been going on for a while, it seems that this change is coming as a surprise to many people (including Simon Peyton Jones). In summary, it generalizes many list operation, e.g., foldr, to be overloaded. There is much to welcome in BBP, but changing the Prelude cannot be done lightly since it really is like changing the language. So I think it's really important for a large number of people to be able to try out such changes before they come into effect, and to have time to let the changes stabilize (you rarely get it right the first time). I've discussed this with a number of people, including Simon PJ, and we have concrete proposals. Proposal 1: * Add a new pragma {-# LANGUAGE Prelude=AlternativePrelude #-} * This is a new feature, but it is easy and low-risk to implement. * Which Prelude you use really is a language choice; appropriate for a LANGUAGE pragma. * Semantics is name-space only: import Prelude (); import AlternativePrelude * No effect on desugaring or typing of built-in syntax (list comprehensions, do-notation etc). * Ship with both old and new prelude. * So now old and new behaviour are easy to achieve, in the module or in a .cabal file. * The question becomes "what is the default". Proposal 2: * Make the default be the old rather than the new. * Altering the default Prelude API should be done slowly, with lots of warning; because all users get it willy-nilly. * Unlike AMP, the change is controversial (clearly). * Easier to make changes to New Prelude if it isn't the default. That's it. Discussing the BBP proposal we also came up with a number of technical questions: Q1 An alternative to Foldable would be class Enumerable t where toList :: t a -> [a] -- Implementations should use 'build' Is Foldable more general (or efficient) than a Enumerable class, plus fusion? Consider a new data type X a. I write foldX :: (a -> b -> b) -> b -> X a -> b foldX = ...lots of code... toList :: X a -> [a] {-# INLINE toList #-} toList x = build (\c n. foldX c n x) So now toList is small and easy to inline. Every good list consumer of a call to toList will turn into a call to foldX, which is what we want. Q2 What are the criteria for being in Foldable? For instance, why are 'sum', 'product' in Foldable, but not 'and', 'or'? Q3 What's the relationship of Foldable to GHC.Exts.IsList? Which also has toList, fromList, and does work with ByteString. * For example, could we use IsList instead of Foldable? Specifically, Foldable does not use its potential power to apply the type constructor t to different arguments. (Unlike Traversable which does.) foldr :: IsList l => (Item l->b->b) -> b -> l -> b -- Lennart This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at http://www.standardchartered.com/en/incorporation-details.html Insofar as this communication contains any market commentary, the market commentary has been prepared by a sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx. Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmark… for important information with respect to derivative products.

39 120

Re: Drastic Prelude changes imminent
by Alec 31 Jan '15

31 Jan '15

On Sat Jan 31 2015 at 01:43:03 AM davean <davean(a)xkcd.com> wrote: > > Personally, I want a language thats good to use. That means constant > improvement. My life gets better by far more then it costs me to update > some code in fairly trivial ways when the language or libraries change. In > fact, Haskell makes updates easy. Why should we instead build up the need > to replace the language with a new one, how is that better? [...] > [...] Lets not > tear our hair out because someone made a bad decision in the 1980s and now > we're stuck with it. I've done that. It was terrible. The world doesn't > need another language that makes that mistake. > +1, Haskell98 is not a suicide pact.

1 0

Upcoming GHC version (was: Re: Drastic Prelude changes imminent)
by Greg Fitzgerald 28 Jan '15

28 Jan '15

If BBP is going to be released as-is, can we please call the next release GHC 8.0? Good stuff: http://semver.org/ Thanks, Greg On Tue, Jan 27, 2015 at 10:22 AM, David Luposchainsky <dluposchainsky(a)googlemail.com> wrote: > Hello *, > > as much as I welcome these changes to the Prelude kitchen sink, I'm > confused about how this does not make the release a major version bump. > It changes half of the functions exposed by default in a dramatic way, > after all. Do we want to keep GHC 8 for a new Report? > > Greetings, > David/quchen > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries

6 5

Re: Drastic Prelude changes imminent
by Greg Weber 27 Jan '15

27 Jan '15

On Tue, Jan 27, 2015 at 2:17 PM, Mikolaj Konarski < mikolaj.konarski(a)gmail.com> wrote: > > We already have a process that works pretty well. Create a wiki page that > > specifies the implementation. Notifying every Haskell user is pointless > if > > there is no specification for them to look at. I have no idea why the > > specification step was skipped for this change. > > Because code was the shortest specification in this case? > Or, alternatively, the specification was too vague, as in, > the most sensible set of changes that make these 5 imports > coexist without an error? Or because the best specification > was a set of detailed, readable commit messages that show > the road from this vague specification to the actual decisions > and code changes? With lots of time in between for others > to offer suggestion for subsequent commits and catch problems? > > I don't mean there's no communication problem, but specifications > are not always a solution. Perhaps a wiki page should list the commits, > as they were created. Or perhaps they were listed somewhere? > None of these rhetorical questions are satisfactory. I understand the need to iterate on a design and start with a vague specification. But by the time something concrete is figured out, it should be explained. Explaining the iteration process with a few of the code examples would answer a lot of the questions here. In the end, the changes have been explained many times over now, just not coherently in one place.

2 2

NumberSieves status/maintenance
by David Feuer 26 Jan '15

26 Jan '15

This package was last updated in 2012, and the linked darcs repository is inaccessible. Do you intend to continue to maintain this package? If not, I would be happy to take over. Thanks, David Feuer

1 0

Problem using Text.Regex on OS X.
by Peter Sumskas 26 Jan '15

26 Jan '15

Hi, I'm new to Haskell so I'm not sure how to solve this issue, yet. I was directed to this list from the IRC channel. Here's the issue: Using GHCi on OS X: Prelude Data.Text> :m Text.Regex Prelude Text.Regex> let r = mkRegex "_" ... eliding successful "Loading package ..." lines ... Loading package regex-compat-0.95.1 ... can't load .so/.DLL for: /Library/Haskell/ghc-7.8.3-x86_64/lib/regex-compat-0.95.1/libHSregex-compat-0.95.1-ghc7.8.3.dylib (dlopen(/Library/Haskell/ghc-7.8.3-x86_64/lib/regex-compat-0.95.1/libHSregex-compat-0.95.1-ghc7.8.3.dylib, 9): Library not loaded: @rpath/libHSmtl-2.1.3.1-ghc7.8.3.dylib Referenced from: /Library/Haskell/ghc-7.8.3-x86_64/lib/regex-compat-0.95.1/libHSregex-compat-0.95.1-ghc7.8.3.dylib Reason: image not found) After running otool over the regex-compat dylib I can see lines like: ... Load command 24 cmd LC_RPATH cmdsize 80 path /Users/mark/Projects/hp/build/package/mtl-2.1.3.1/build/dist/build (offset 12) ... Which is not a path that is relevant to my installation. It was suggested that this may be an error in the way packages are being built for OS X. Whatever the cause, I'm bringing it to the attention of this list in order to gain information on what course to take in addressing this issue. Thanks for your help. Kind regards, Peter Sumskas.

2 1