- Libraries - Haskell.org

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

Re: List-0.4.3 (and hexpat)
by Christian Maeder 16 Aug '12

16 Aug '12

Thanks for your prompt response and action! Am 15.08.2012 23:46, schrieb Yair Chuchem: > Hi Christian, > > Please try again now (after a cabal update). > I uploaded List-0.4.4 which removes mapMaybe, and then also uploaded > List-0.5.0 which re-adds it. > hexpat should now be using List-0.4.4 as it wants List < 0.5 > > I'll follow up with a few steps: > * Make myself a rule to test installing hexpat before I push updates to > List in future. > * Contact Stephen to change hexpat to not use unqualified open imports, > at least for List. His email was not in the package description. Christian > * Add docs to my package warning users that using it with unqualified > open imports may be more dangerous than usual (btw unqualified open > imports are always dangerous) because List exports functions which > generalize Prelude functions and shares their names by design. Similar > to how Control.Category exports "." and "id". > > Cheers & Happy coding, > Yair

1 0

List-0.4.3
by Christian Maeder 15 Aug '12

15 Aug '12

Hi, The change in package List-0.4.3 cause hexpat to fail. (It works with List-0.4.2 without "mapMaybe") C. Resolving dependencies... Downloading hexpat-0.20.2... Configuring hexpat-0.20.2... Building hexpat-0.20.2... Preprocessing library hexpat-0.20.2... [ 1 of 12] Compiling Text.XML.Expat.Internal.IO ( Text/XML/Expat/Internal/IO.hs, dist/build/Text/XML/Expat/Internal/IO.o ) [ 2 of 12] Compiling Text.XML.Expat.SAX ( Text/XML/Expat/SAX.hs, dist/build/Text/XML/Expat/SAX.o ) [ 3 of 12] Compiling Text.XML.Expat.Internal.NodeClass ( Text/XML/Expat/Internal/NodeClass.hs, dist/build/Text/XML/Expat/Internal/NodeClass.o ) [ 4 of 12] Compiling Text.XML.Expat.Internal.Qualified ( Text/XML/Expat/Internal/Qualified.hs, dist/build/Text/XML/Expat/Internal/Qualified.o ) [ 5 of 12] Compiling Text.XML.Expat.Internal.Namespaced ( Text/XML/Expat/Internal/Namespaced.hs, dist/build/Text/XML/Expat/Internal/Namespaced.o ) [ 6 of 12] Compiling Text.XML.Expat.Tree ( Text/XML/Expat/Tree.hs, dist/build/Text/XML/Expat/Tree.o ) [ 7 of 12] Compiling Text.XML.Expat.Cursor ( Text/XML/Expat/Cursor.hs, dist/build/Text/XML/Expat/Cursor.o ) [ 8 of 12] Compiling Text.XML.Expat.Internal.DocumentClass ( Text/XML/Expat/Internal/DocumentClass.hs, dist/build/Text/XML/Expat/Internal/DocumentClass.o ) [ 9 of 12] Compiling Text.XML.Expat.Extended ( Text/XML/Expat/Extended.hs, dist/build/Text/XML/Expat/Extended.o ) Text/XML/Expat/Extended.hs:372:25: Ambiguous occurrence `mapMaybe' It could refer to either `Data.List.Class.mapMaybe', imported from `Data.List.Class' at Text/XML/Expat/Extended.hs:83:1-22 or `Data.Maybe.mapMaybe', imported from `Data.Maybe' at Text/XML/Expat/Extended.hs:84:1-17 cabal: Error: some packages failed to install: hexpat-0.20.2 failed during the building phase. The exception was: ExitFailure 1

1 0

gearing up for 2012.4.0.0
by Mark Lentczner 14 Aug '12

14 Aug '12

It's that time again.... time to get cooking on another tasty Haskell Platform release! Here's my updated timeline for 2012.4.0.0, target: *November 12th, 2012* - *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 - *October 15th, 2012* - First candidates - *October 29th, 2012* - Open issues resolved, Second candidates - *November 5th, 2012* - Final release candidates *If you are maintainer of a library in the platform:* Please start thinking about which version of your library should be in the release. If it will require coordination with versions of other libraries in the platform, now is the time to start coordinating. In mid-september, we will need to hear from the maintainers which version should be included: *I will not automatically bump to the latest version on Hackage for this release.* * * *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>. *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. *If you are GHC Central: *I couldn't find a timeline for 7.6. Will that have hit a stable release by October 1st, or should we be planning on shipping 7.4.2 (which I think would be fine.) *If you are a packager or builder of HP releases: *Please review the trac ticket list <http://trac.haskell.org/haskell-platform/report/3>. Please edit tickets to reflect reality: Close things that are fixed or won't ever be done. Edit descriptions with more information if you have it. But most importantly, please assign milestones correctly: If you are going to fix something this time - put it in the 2012.4.0.0 milestone. If it is for the future, put it in Blue Sky. - Mark "mzero" Lentczner, Chef de la Release

3 3