August 2012 - Libraries

Call for consensus: addition of split package to platform
by Brent Yorgey 24 Sep '12

24 Sep '12

Hi everyone, Following the great feedback I got on the initial proposal, and after testing with the GHC 7.6 release candidate, I have just released split-0.2.0.0, which I am proposing for inclusion in the HP. The full proposal, links to previous discussion, etc. can be found on the wiki: http://trac.haskell.org/haskell-platform/wiki/Proposals/split Comments, questions, constructive criticism, etc. are still welcome, but this time around I hope we can build a consensus as to whether it should go in the platform or not. I would also like people's opinions on the one big question remaining: whether to use cabal's mechanisms to conditionally include some code, allowing the 'build' function to be taken from GHC.Exts when available, or defined manually otherwise. This would make split fully H2010-compatible. The currently released version does NOT include this, so it is H2010-compatible but GHC specific. The options are: 1) just use a generic version of 'build' (simplest option) 2) use only GHC's version of build (slightly faster) 3) do the conditional thing to choose between 1) and 2) at compile time (most general but most complicated/cumbersome) -Brent

2 2

System.Process.ByteString.readProcess, readProcessWithExitCode
by David Fox 14 Sep '12

14 Sep '12

Attached is a module containing ByteString analogs of two functions from System.Process: readProcess and readProcessWithExitCode. I use these a lot and would love to see them incorporated into a standard library, though I'm not sure which one.

4 10

Data.Graph
by Evan Laforge 03 Sep '12

03 Sep '12

I just fixed a bug in my program that came about because the same graph constructed in different orders compared inequal. E.g.: buildG (0, 2) [(0, 1), (0, 2)] /= buildG (0, 2) [(0, 2), (0, 1)] It seems to me that these should compare equal. This was easy for me to do since I wrap Graph in a newtype, but it's hard to do for Graph itself, since it's defined as a type synonym over Data.Array. Do people agree that (==) is incorrect for Data.Graph, or is there a legitimate difference between the two graphs? If people agree, what can be done to fix Data.Graph? Should be add Data.Graph2 that is defined as a real type and start anew from there? In general, it seems to me Data.Graph is very basic and has not received any love for a long time. It's a thin wrapper over Data.Array, which is one of the more error-prone ornery APIs out there. To use it I wound up writing lots of little utility functions to do things like add or remove edges which were fiddly and error prone. I just noticed a package graph-wrapper, with the description "A wrapper around the standard Data.Graph with a less awkward interface", so I guess I'm not the only person to have felt that way. Wouldn't it be nice to start taking steps toward having a graph library in the stdlib that people actually like?

7 6

Removing the .Safe modules from vector (was: Haskell Platform proposal: Add the vector package)
by Johan Tibell 31 Aug '12

31 Aug '12

Hi all, After reading the Safe Haskell paper today, I got the impression that no one actually wants the .Safe modules currently in vector. If vector was to be made Safe Haskell friendly, we should instead add .Unsafe modules (and have the rest of the modules declared Trustworthy). Having .Unsafe modules is better than having .Safe modules, because * there are many more safe functions than unsafe functions, and * Haskell is by default safe, so having modules called .Safe is a bit like having modules called .Pure. There's precedence for having .Unsafe modules in e.g. bytestring. If that's the case, and if Roman agrees, I suggest we release a new major version that * removes all the .Safe modules [1], * adds new .Unsafe modules, and * marks the functions that are now exported through the .Unsafe modules deprecated in their original (non-.Unsafe) location. I suggest that the deprecation doesn't involve an actual deprecation pragma in this release [2], but instead just a comment. A future major release could add the deprecation pragma and another major release after that could remove the actual functions. Actually removing functions causes huge Hackage churn so I suggest that we don't do that until the new .Unsafe modules have been around for a long time. 1. Normally I would suggest a deprecation period before removing functions from an API, but I just searched through all of Hackage and there's only a single package (bitvec) that makes use of the .Safe API 2. While deprecation pragmas sound good in theory there isn't much library authors can do to make the warning go away. An author can migrate to the new API, but in practice authors need to support a couple of releases of each library. Cheers, Johan

11 14

HP 2012.4.0.0 -- Call for Proposals
by Mark Lentczner 29 Aug '12

29 Aug '12

While proposals for changes to Haskell Platform can be made at any time, this call is for proposals that would like to land in the 2012.4.0.0 release. The 2012.4.0.0 is scheduled for November 12th, 2012. In order for a proposal to made it in that release, it needs to meet the following timeline: - *August 20th, 2012* - Call for proposals for additions and changes - *September 17th, 2012* - Call for proposals ends (no more proposals considered) - *October 1st, 2012* - Proposals decided, Initial version list *If you are a maintainer of a library that you'd like to be in the platform: * Now is the time to get a clean version on Hackage, and then put together a proposal for the haskell-platform list. Please see the process for Adding Packages <http://trac.haskell.org/haskell-platform/wiki/AddingPackages>. *Outstanding work:* - There is a proposal to include vector-0.9.1 in the platform - There is a ticket to consider including OpenGLRaw — Ticket #167<http://trac.haskell.org/haskell-platform/ticket/167> - There are tickets to consider removing OpenGL and GLUT — Ticket #57<http://trac.haskell.org/haskell-platform/ticket/57>, Ticket #58 <http://trac.haskell.org/haskell-platform/ticket/58> - There is a ticket about binary being in the platform without being part of it — Ticket #191<http://trac.haskell.org/haskell-platform/ticket/191> - There is a ticket about needing hscolour to build the platform, but it isn't part of it — Ticket #160<http://trac.haskell.org/haskell-platform/ticket/160> Please not that none of the tickets is a proposal before the list yet. If the maintainer of those libraries, or someone else, want to propose a change based on those tickets, now is the time to do so. In any event, I will close those tickets on September 17th. *If you are part of the reviewing process:* Traditionally, proposals have been accompanied by lengthly discussions, often resulting in deep API design confabs. As we are approaching a release, I'd like to ask all to consider making this round more succinct if at all possible. In particular, it would be great if proposals were keyed to specific revisions of a library to be considered. If consensus is that something needs to be changed before inclusion - it would be best if maintainers took that input into account, turned another library version and placed that up for consideration. Please note the schedule: I'm going to hold October 1st firm. — Mark "proposed in a restaurant in front of friends" Lentczner

15 24

Proposal: unsnoc, unsafeInit and unsafeLast for the bytestring library
by Mikhail Vorozhtsov 28 Aug '12

28 Aug '12

Hi. I propose to add the missing counterparts of `uncons` and `unsafeHead/Tail` functions to the bytestring library. Discussion deadline: 2 weeks The patch is attached.

5 10

Signature of Control.Monad when and unless
by Oren Ben-Kiki 26 Aug '12

26 Aug '12

I understand why the normal signature is: when :: Monad m => Bool -> m () -> m () unless :: Monad m => Bool -> m () -> m () But why isn't there also: when_ :: Monad m => Bool -> m a -> m () unless_ :: Monad m => Bool -> m a -> m () That is, I agree that results shouldn't be discarded "by default", but it should be easy to get rid of them if they are unneeded. Thanks, Oren Ben-Kiki

6 5

Add binary and/or cereal to the Haskell Platform
by Yitzchak Gale 22 Aug '12

22 Aug '12

I see that several years ago a proposal page was prepared for adding the binary package to the Haskell Platform, but it was never actually submitted as a proposal. http://trac.haskell.org/haskell-platform/wiki/Proposals/binary I think the reason it was not submitted was that things were in flux at that time regarding the binary and cereal packages. Now the situation has settled down. I think one or both of those packages ought to be added to the platform. Any opinions? Thanks, Yitz

5 8

addForeignPtrFinalizer - finalizers run in FIFO or LIFO order?
by Henning Thielemann 18 Aug '12

18 Aug '12

The doc of base-4.5:Foreign.ForeignPtr.addForeignPtrFinalizer states: "This function adds a finalizer to the given foreign object. The finalizer will run before all other finalizers for the same object which have already been registered." I do addForeignPtrFinalizer finalize1 fp addForeignPtrFinalizer finalize2 fp and let the finalizers print something when they are started. I get the output: finalizer1 finalizer2 This indicates that the newly added finalizer is run _after_ the finalizers that are already registered. Is this a documentation bug or a bug in the base library?

3 6

maybeRead in base
by Tom Murphy 16 Aug '12

16 Aug '12

It would be great to have maybeRead in base in time for the next Haskell Platform release. There's been talk about including it several times, but it's remained as a utility function in other libraries (Network.CGI, for example, if I'm remembering right). Tom

5 5