April 2014 - Libraries

Function to add to Data.List
by John Wiegley 10 Apr '14

10 Apr '14

I heard a talk that mentioned this transform today at Hac NYC, and was surprised it wasn't already in Data.List: -- | Sort a list using a key on each element. This implements the -- decorate-sort-undecorate paradigm, also called a Schwarzian transform. sortByKey :: Ord b => (a -> b) -> [a] -> [a] sortByKey f = map snd . sortBy (comparing fst) . map (\x -> (f x, x)) I would like to propose adding it. John

14 21

What To Expect When You're a Platform Library Maintainer
by Mark Lentczner 10 Apr '14

10 Apr '14

I've been meaning to write this for a while... Recent discussions spurred me to get on it. I present: "What To Expect When You're a Platform Library Maintainer" Having your library as part of the Platform has its plusses: * Your library will get lots of users, which in turn will get it used, tested, and maybe some contributors. * That functionality becomes part of what developers perceive as "easily doable with Haskell" * Fame! (Well, functional fame...) There are downsides too: * You'll get bug reports. Some real, some bizarre. * You have to subscribe to a low-volume mailing list. * Every six months or so you'll get e-mail from me asking what the current stable version is. But the real thing to think about is the responsibility: * Once in the platform, we're telling people to use it and depend on it... which means you need to be sure it is dependable. * You are committing to keeping the API stable. Which means long term (years) forward and backward compatibility: ** Clients written to your API today should continue to compile and work against future versions of the API, several years running. ** Clients written to your API today should be able to, without much trouble, work with the past few (2? 3?) releases of the platform. * You can only depend on other packages that are in the platform, and are committing to that restriction going forward. (That isn't to say that you can't lobby to get some other package you'd like to use into the platform... but just don't assume it will.) * Your package should help work toward eliminating "cabal hell". This generally means adhering to the PVP, and having reasonable values there. * Tests. Please. * You should have a public repo on GitHub or someplace with similar availability. * You should have a contact e-mail publicly available. If you want to stay anonymous, having a package in the platform isn't the way (see "Fame!" above). * You aught to have back-up maintainers. That way if you are on vacation or need to take leave or give up the project - there is someone else to keep it going. * Twice a year expect a short flurry of messages and checking to make sure all is well and compiles with the latest of everything else that goes into the platform, including GHC. For many this is usually very little work... then occasionally GHC 7.n+2 comes along and we all have stuff to do! I know it sounds like a lot, but isn't that bad, and it is worth it: Successful programming systems (think PHP or Python or Java) have succeeded in large part because they have a rich set of platform libraries that "just work". It is the development experience with that platform that makes developers decide a programming language is viable. The success of Haskell will be largely based on how much we can all pitch in to make the platform libraries a "smooth sailing" experience, "batteries included". - Mark

1 0

Proposal: add createPipe to base
by Johan Tibell 07 Apr '14

07 Apr '14

I've written a cross-platform* implementation of the pipe() syscall, currently for use within Cabal: createPipe :: IO (Handle, Handle) https://github.com/haskell/cabal/blob/master/Cabal/tests/Distribution/Compa… It's a bit of a shame to leave it in Cabal as it's generally useful. I propose we add it to System.IO. Note that we'd have to copy the 5 lines in System.Posix.IO.createPipe into base as the above implementation would otherwise depend on the unix package. Discussion period: 3 weeks. * Only tested on OS X, Windows, and Linux.

9 11

We need to add role annotations for 7.8
by Richard Eisenberg 02 Apr '14

02 Apr '14

Hi libraries, Johan, Edward, tl;dr: We really should add role annotations to the libraries that ship with GHC 7.8. In November, I sent this out: http://www.haskell.org/pipermail/libraries/2013-November/021707.html It got several good responses. Some time later, Joachim and I noticed that no action was taken, so we made a bug report, #8718, with a milestone of 7.8.1. I believe we both assumed that would take care of it. However, Simon PJ and I were surprised earlier this week to discover that Map and Set still do not have role annotations. Perhaps the GHC Trac isn't the right place for libraries issues, but posting here didn't quite work, so that seemed like the logical next step. In any case, now that we have the ability to prevent abuses of datatypes like Map and Set through erroneous use of GeneralizedNewtypeDeriving (and the new `coerce`), we should take advantage of this fact for 7.8. See my earlier email for a full explanation. Possibly folks' unfamiliarity with roles are in part to blame for not adding these role annotations. I am happy to help sort out what goes where. But, I need to work with someone with an intimate familiarity with the libraries themselves to help determine what the correct annotations are. For example, Map's first parameter should be nominal (its Ord instance is very relevant) but its second should be representational (there are no particular invariants related to the values of a map). Map is straightforward in this respect; other types probably aren't. Furthermore, I don't have anywhere near a complete list of what even needs attention. (It should be any type abstractly exported from a library.) Can someone help? I've included Johan as the most recent uploader of `containers` and Edward as the head of the core libraries committee. Thanks! Richard

23 74

New GHC Features for 7.10.1 and Beyond
by Gershom Bazerman 01 Apr '14

01 Apr '14

There's been lots of exciting work going into the forthcoming GHC 7.8.1 release. But even with all these new features, our language is far from complete and I wouldn't want the GHC team to rest on their laurels. Especially with so much renewed community involvement in GHC development, it seems appropriate to share some ideas some of us have been discussing for future releases, and take a poll of community consensus regarding which ones people might be excited to jump in and help out with, or might find particularly helpful. One important area that needs work is exceptions. These are famously difficult, and many libraries have been written to provide checked exceptions, or unify error and exceptions in various ways. It seems to me that the problem, all along, has been that we've decided to give Haskell _imprecise exceptions_ with special semantics. It would alleviate a great deal of confusion if we implemented a -fprecise-exceptions flag that remedied this. Additionally, while we have long known that Haskell is not a "lazy" language but a "non-strict" one, our leading compiler only rarely takes advantage of this. It is well known that for every program there is a reduction strategy that preserves non-strict semantics while using as few reductions as possible. This is known as the "optimal reduction" strategy, and it is calculable and well understood. We should put some work into a -foptimal-reduction flag. Another important area of research is quantum computation. The D-Wave Two, with 512 qbits, is a commercially available quantum computer now deployed in a few leading institutions. As more and more people begin to purchase D-Wave systems for home hacking, every language worth its salt will need to be able to target this system. Now that cross compilation is more fully supported, it would be good to start putting work into a dwave backend. We've also seen a lot of interest in distribution and cloud computing. From the articles I've read, efficient concurrent programming involves using node.js, so I think we should put some work into writing a new-new-new-IO Manager built on top of this technology. Furthermore, it's ridiculous that while Haskell allows simple concurrent and distributed programming, it offers no simple way to set up a distributed environment. Work should be put into a compiler mode that provisions cloud resources automatically and distributes the target binary among them, with a flag such as: -fvia-s3 _credit_card_number_ There are a few cases where a good idea in GHC can be taken further, and I don't know why we haven't tried already. For example, we've found that despite introducing some occasional problems, the state hack also has drastically improved performance. Since it works so well, we should provide a dual to -fno-state-hack, -fmore-state-hack, for those who really need every last drop of performance. Similarly, now we have type holes that let us see what types should be inserted in various spots. -fvalue-holes is the next logical step, to tell us what terms we should be writing. Also, while we've put so much emphasis on correctness, we've also loosened the bolts optionally the other way, with flags such as -XIncoherentInstances. Along the same lines, I would like to introduce -XImpossibleInstances to let us express such useful things as "instance Int String," "instance IO Comonad," and "instance data if". -fdefer-type-errors allows us to defer type errors to runtime. Having spent some time with JavaScript lately, I think this doesn't go nearly far enough. It would be good to run programs with other sorts of problems as well, for educational purposes and for quick hacking. So work should be put into a -fdefer-scope-errors flag, as well as -fon-error-resume-next, which has done wonders for the resilience of Visual Basic code (see also the wildly useful ability to set the top level error handler in PHP). With all these features put together, we have a powerful new way to approach Haskell programming, and it would be good to enable them by default on .ilhs files (illiterate haskell). It also was pointed out to me recently by Jason Dagit that while we have had debates and confusion over closed and open type families and functions for years, topologists have solved this problem elegantly. With some basic point set topology under one's belt, a -XClopenTypeFamilies extension seems almost trivial to implement. Finally, I'm very sorry to see that my proposal for youtube syntax has languished, and I hope it can be revived: http://www.haskell.org/pipermail/haskell-cafe/2012-April/100527.html HTH HAND, Gershom

5 4

vector: ‘ANN type’ without GHCi
by Nikita Karetnikov 01 Apr '14

01 Apr '14

The latest Hackage version and HEAD fail to build on mips64el due to the ANN pragma in ‘Data/Vector/Fusion/Stream/Monadic.hs’: [ 5 of 21] Compiling Data.Vector.Fusion.Stream.Monadic ( Data/Vector/Fusion/Stream/Monadic.hs, dist/build/Data/Vector/Fusion/Stream/Monadic.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for mipsel-unknown-linux): Cant do annotations without GHCi {Data/Vector/Fusion/Stream/Monadic.hs:104:19-33} base:GHC.Exts.ForceSpecConstr{d r2i8} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Here’s the relevant part of the code: data SPEC = SPEC | SPEC2 #if __GLASGOW_HASKELL__ >= 700 {-# ANN type SPEC ForceSpecConstr #-} #endif Is it possible to use CPP along with some configure flag to determine if GHCi is available, and if it is not, skip the said pragma? I tested the Hackage version, and it builds fine if I comment out the mentioned lines. Does the lack of the pragma make a big difference? (The relevant section of the GHC manual is very brief.)

5 4