- Libraries - Haskell.org

GHC 7.10 Prelude: we need your opinion
by Simon Peyton Jones 10 Feb '15

10 Feb '15

[You have probably seen this already, but I stupidly failed to cross-post it to libraries(a)haskell.org<mailto:libraries@haskell.org>, and am now doing so. libraries@ is actually the right list for debate about the issues.] Haskell Friends This email asks for your help in deciding how to proceed with some Prelude changes in GHC 7.10. Please read on, but all the info is also at the survey link, here: http://goo.gl/forms/XP1W2JdfpX. Deadline is 21 Feb. The Core Libraries Committee (CLC) is responsible for developing the core libraries that ship with GHC. This is an important but painstaking task, and we owe the CLC a big vote of thanks for taking it on. For over a year the CLC has been working on integrating the Foldable and Traversable classes (shipped in base in GHC 7.8) into the core libraries, and into the Prelude in particular. Detailed planning for GHC 7.10 started in the autumn of 2014, and the CLC went ahead with this integration. Then we had a failure of communication. As these changes affect the Prelude, which is in scope for all users of Haskell, these changes should be held to a higher bar than the regular libraries@ review process. However, the Foldable/Traversable changes were not particularly well signposted. Many people have only recently woken up to them, and some have objected (both in principle and detail). This is an extremely unfortunate situation. On the one hand we are at RC2 for GHC 7.10, so library authors have invested effort in updating their libraries to the new Prelude. On the other, altering the Prelude is in effect altering the language, something we take pretty seriously. We should have had this debate back in 2014, but here we are, and it is unproductive to argue about whose fault it is. We all share responsibility. We need to decide what to do now. A small group of us met by Skype and we've decided to do this: · Push back GHC 7.10's release by at least a month, to late March. This delay also gives us breathing space to address an unrelated show-stopping bug, Trac #9858. · Invite input from the Haskell community on which of two approaches to adopt (this survey<http://goo.gl/forms/XP1W2JdfpX>). The main questions revolve around impact on the Haskell ecosystem (commercial applications, teaching, libraries, etc etc), so we want to ask your opinion rather than guess it. · Ask Simon Marlow and Simon Peyton Jones to decide which approach to follow for GHC 7.10. Wiki pages have been created summarizing these two primary alternatives, including many more points and counter-points and technical details: · Overall summary: https://ghc.haskell.org/trac/ghc/wiki/Prelude710<https://www.google.com/url?q=https%3A%2F%2Fghc.haskell.org%2Ftrac%2Fghc%2Fw…> · Details of Plan List: https://ghc.haskell.org/trac/ghc/wiki/Prelude710/List<https://www.google.com/url?q=https%3A%2F%2Fghc.haskell.org%2Ftrac%2Fghc%2Fw…> · Details of Plan FTP: https://ghc.haskell.org/trac/ghc/wiki/Prelude710/FTP<https://www.google.com/url?q=https%3A%2F%2Fghc.haskell.org%2Ftrac%2Fghc%2Fw…> This survey invites your input on which plan we should follow. Would you please · Read the details of the alternative plans on the three wiki pages above · Add your response to the survey<http://goo.gl/forms/XP1W2JdfpX> Please do read the background. Well-informed responses will help. Thank you! DEADLINE: 21 February 2015 Simon PJ

1 0

Data.Graph nitpicks
by Andreas Voellmy 10 Feb '15

10 Feb '15

Hi folks, I was just using the stronglyConnComp function in Data.Graph and found some minor annoying things: 1. stronglyConnComp takes an out-list as input. On the other hand, none of the other graph algorithms, like dfs, etc do this. stronglyConnComp seems to basically be an algorithm on graphs, so why doesn't it take the graph as input? Can we change stronglyConnComp to take a graph as input? That would make the interface more uniform. 2. Why is stronglyConnComp in a special haddock section whereas all the other algorithms are in the "Algorithms" section? How about we group it with all the other algorithms? 3. Why are there are so few instances of SCC? In particular, why not derive Show and Eq? Cheers, Andi

3 2

Re: Drastic Prelude changes imminent
by malcolm.wallace 04 Feb '15

04 Feb '15

Perhaps this discomfort points to another possible way forward: remove from the Prelude all functions that were formerly list-y, and now Foldable/Traversable. Make it so that you must import Data.List if you want the List versions, or Data.Foldable if you want the generalised versions. Of course, it would be a change causing a lot of breakage in existing code, but then, I have never experienced a major release of ghc that did not break existing code. Regards, Malcolm On 04 Feb, 2015,at 04:14 PM, Christopher Done <chrisdone(a)gmail.com> wrote: Looking at the generalizations in Data.List I find them pretty odd now when I think about it. I'd expect Data.List functions to be monomorphic to lists, just like I expect functions in Data.Map to be monomorphic to maps. Now there might be generalized versions of these functions in e.g. the Prelude, but generalizing Data.List means that I don't even have the monomorphic versions available if I want to resolve ambiguity by using them*. Sums up my feelings exactly. Data.Map, Data.List, etc. should be monomorphic. Adding generalized functions in Data.List is a little baffling. _______________________________________________ Libraries mailing list Libraries(a)haskell.org http://www.haskell.org/mailman/listinfo/libraries

2 1

Re: Drastic Prelude changes imminent
by davean 03 Feb '15

03 Feb '15

Ah yes. That is, strictly speaking not code. I suppose it could count as breakage also, but I think it is far less likely to cause confusion though as they're clearly asking about implementation and getting an answer that its changed. On Tue, Feb 3, 2015 at 2:41 PM, Erik Hesselink <hesselink(a)gmail.com> wrote: > On Tue, Feb 3, 2015 at 8:32 PM, davean <davean(a)xkcd.com> wrote: > > On Tue, Feb 3, 2015 at 2:20 PM, Erik Hesselink <hesselink(a)gmail.com> > wrote: > >> > >> > 2. Breakage of existing tutorials/documentation > >> > >> I was just wondering which of these you were alluding to. Turns out > >> it's all of them :) I'm surprised you mention breakage of code, since > >> in my experience most of the breakage in GHC 7.10 I've seen in my own > >> packages and the Stackage builds is due to other factors: the > >> Applicative/Monad changes, time 1.5, etc. It would be interesting (but > >> time consuming) to gather some statistics on this. The breakage of > >> tutorials is unfortunate, yes. > > > > > > So how bad is the breakage of tutorial code really? Looking around almost > > all of it has a full top level type which makes it still work. I've only > > looked for a few minutes but my first impression is that not much breaks > > with this. Is this just a theory or have people actually determined that > > tutorial code breaks? > > > > (Actually, I've found plenty of broken tutorial code, but it wasn't due > to > > anything in prelude. Our standard library churn seems much worse on > > tutorials I've looked at then this seems to be.) > > I think the 'breakage' is mostly used as mentioning things that work > on lists, while they now work on Foldable/Traversables. For example, > LYAH mentions "length takes a list and returns its length, > obviously.", which isn't true anymore in the strictest sense, it takes > any Foldable. However, you could argue that this text is just > specialization, and that it's still true. There seem to be no things > that are generalized in the section about types, and soon after type > classes are already introduced. Real World Haskell is slightly more > "broken", for example, it lists: > > ghci> :type null > null :: [a] -> Bool > > Which isn't true anymore, it would now give "Foldable t => t a -> Bool". > > Regards, > > Erik > > P.S. You didn't send your message to haskell-cafe. Feel free to > forward it including this reply if you want. >

2 1

Proposal: Add mapWithIndex to Data.List
by David Feuer 01 Feb '15

01 Feb '15

Vectors offer `imap` and sequences offer `mapWithIndex`. I think lists deserve to have something like this too. The obvious implementation, using `zipWith`, is unlikely to be the most efficient (because foldr/build fusion doesn't handle zips so wonderfully). To a first approximation: mapWithIndex :: (Int -> a -> b) -> [a] -> [b] mapWithIndex f xs = build $ \c n -> let go x cont !i = f i x `c` cont (i+1) in foldr go (`seq` n) 0

2 4

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