- Libraries - Haskell.org

Unboxed Vectors of newtype'd values
by Ben Gamari 06 Jun '12

06 Jun '12

One of the reasons I find Haskell so well suited to my work is its ability to easily work with large quantities of data. In particular, I find myself using Data.Vector.Unbox quite frequently. Another of my reasons for using Haskell is the type safety it provides. I find myself using newtypes very frequently to force myself to think about invariants that a more weakly typed language would allow me to simply ignore. Sadly, these two features don't interact particularly well. While the Data.Vector.Unbox documentation claims that "Implementing unboxed vectors for new data types can be very easy", it then goes on to list an abridged version of the Complex instance---dozens of lines of code. While this code certainly isn't difficult to write, it is time consuming, error-prone, and, above else, utterly mind deadeningly dull (making it quite uncharacteristic for Haskell). So dull that I generally avoid newtypes at all cost in code that might need to use unboxed vectors. This boilerplate is largely due to Vector's use of type families as this precludes the use of (the otherwise quite cunning) GeneralizedNewtypeDeriving to automatically derive the necessary instances. What can be done to fix this unfortunate state of affairs? The obvious solution here seems to be Template Haskell, but this seems a bit of an unfortunate hack around what might be a deficiency in the type families mechanism (or at least this application of it). The newtype package provides a nice mechanism to pack and unpack newtypes, but providing blanket Unbox instances for Newtype instances seems like an awful idea (and, frankly, I'm not sure how this would work with type families). Other than these two possibilities I am at a loss. Thoughts? I'd appreciate any ideas folks could offer. Cheers, - Ben

10 26

Re: [Haskell] Types of when and unless in Control.Monad
by malcolm.wallace 06 Jun '12

06 Jun '12

On Jun 06, 2012, at 08:44 AM, Andreas Abel <andreas.abel(a)ifi.lmu.de> wrote: > Well, but nothing in the type system prevents you from writing > > mapM f xs >> cont > > or > > do mapM f xs > cont > > so you are not warned of a space leak in the common situations anyway, At least the second form will trigger a warning in GHC (although admittedly not from the type system, but from -fwarn-unused-do-bind). It is a jolly useful warning at times. Regards, Malcolm

1 0

[ANNOUNCE] cereal-0.3.5.2
by Trevor Elliott 05 Jun '12

05 Jun '12

Hi Everyone, I'm happy to announce version 0.3.5.2[1] of the cereal serialization library. This is a bugfix release, mostly improving performance characteristics of the library. One noteable change is with runGetLazy, which will now perform as expected when a parser attempts to consume more input than is available. Happy hacking! --trevor [1] http://hackage.haskell.org/package/cereal-0.3.5.2

1 0

Re: [Haskell] Types of when and unless in Control.Monad
by Ivan Lazar Miljenovic 05 Jun '12

05 Jun '12

On 22 April 2012 21:39, Christian Höner zu Siederdissen <choener(a)tbi.univie.ac.at> wrote: > * Julian Gilbey <julian(a)d-and-j.net> [22.04.2012 09:22]: >> On Sat, Apr 21, 2012 at 08:28:27PM -0500, Strake wrote: >> > On 21/04/2012, Andreas Abel <andreas.abel(a)ifi.lmu.de> wrote: >> > > to avoid silly "return ()" statements like in >> > > >> > > when cond $ do >> > > monadicComputationWhoseResultIWantToDiscard >> > > return () >> > >> > (when cond ∘ void) monadicComputationWhoseResultIWantToDiscard >> > or >> > when cond $ () <$ monadicComputationWhoseResultIWantToDiscard >> >> How is that simpler than >> >> when cond monadicComputationWhoseResultIWantToDiscard >> >> which it would be with the suggested new type? >> >> Julian > > Wouldn't "when_" and "unless_" or similar be better? I'd probably like > to have the compiler annoy me, since it is not clear that I want to > discard the result. If I really want to discard, I should have to make > it clear as there is probably a good reason for the inner function to > return a result in the first place? Agreed; I'm not sure if I agree with having such functionality (Henning makes some good points), but if people deem it desirable then I think it would be better to have them with new names for the reasons you state. -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

4 7

The 'encoding' package maintainer?
by Boris Kropivnitsky 05 Jun '12

05 Jun '12

Hello, I am looking for the maintainer of the 'encoding' library. I tried to use it for my little project, but it turned out that it has some issues and needs some love. So I've made a few fixes and it now works reasonably well. I thought the community will benefit if the new version is made available. I've tried to contact the author listed in the .cabal file but had no luck. So I thought I'd ask for help here. Cheers, Boris Kropivnitsky

2 2

Announce: Haskell Platform 2012.2.0.0
by Mark Lentczner 03 Jun '12

03 Jun '12

We're pleased to announce the next release of Haskell Platform: a single, standard Haskell distribution for everyone. Download Haskell Platform 2012.2.0.0: http://haskell.org/platform/ The specification, along with installers (including Windows, Macintosh, and Unix installers for a full Haskell environment) are available. Notable version changes with this release: ghc 7.4.1 cabal 1.14 & cabal-install 0.14 mtl 2.1.1 & transformers 0.3.0.0 alex 3.0.1 full package and version list: http://hackage.haskell.org/platform/changelog.html Thanks to: Joachim Breitner, George Colpitts, Duncan Coutts, Jason Dagit, Chris Dornan, Yitzchak Gale, Mikhail Glushenkov, Andres Löh, Gábor Páli, Jens Petersen, Don Stewart, David Terei, Johan Tibell, & Mark Wright for their efforts and help in putting together this release. -- The Platform Infrastructure Team Mark Lentczner, release manager --------------------------------------------------------------------- The Haskell Platform is a single, standard Haskell distribution for every system, in the form of a blessed library and tool suite for Haskell distilled from the thousands of libraries on Hackage, along with installers for a wide variety of systems. It saves developers work picking and choosing the best Haskell libraries and tools to use for a task. When you install the Haskell Platform, you get the latest stable compiler, an expanded set of core libraries, additional development tools, and cabal-install – so you can download anything else you need from Hackage.

4 4

SafeSemapore
by Chris Kuklewicz 02 Jun '12

02 Jun '12

This message is in three parts: a problem, a solution, and a request for help. The problem is that Control.Concurrent.QSem, QSemN, and SampleVar are all still broken. GHC ticket #3160 is still open [1]. These three synchronization mechanisms can be irretrievable broken by a killThread on a blocked waiter. The solution is that I am please to announce that SafeSemaphore has been updated to 0.9.0 on hackage [2] and github. These provides safe solutions to replace QSem and QSemN, actually several such solutions. See the github [2] page (scroll down for README) for a summary of all the modules. The request for help is that I would like to unbreak the Haskell Platform by replacing the guts of QSem, QSemN, and SampleVar with SafeSemaphore. Do you think my replacement is correct or buggy? Can we get #3160 closed? Replacing these will preserve their API but may tinker with corner case undocumented behavior. Should waiters block in FIFO order? Should QSemN starve big or small requests to be fairer? [1] http://hackage.haskell.org/trac/ghc/ticket/3160 (three years old!) [2] http://hackage.haskell.org/package/SafeSemaphore/ [3] https://github.com/ChrisKuklewicz/SafeSemaphore Sincerely, Chris Kuklewicz

2 1

Fix risk of dead-lock in documentation of Control.Concurrent
by Bas van Dijk 27 May '12

27 May '12

The current documentation of Control.Concurrent proposes a function to wait for a child thread to complete: myForkIO :: IO () -> IO (MVar ()) myForkIO io = do mvar <- newEmptyMVar forkIO (io `finally` putMVar mvar ()) return mvar This function has the risk of causing a dead-lock. If an asynchronous exception if thrown before the putMVar exception handler is installed the mvar will remain empty. This causes a dead-lock when the mvar is taken. The patch attached to the ticket [6126] fixes this problem by correctly masking asynchronous exceptions before forking. Also, instead of returning the mvar it returns a computation that waits for the child thread to complete. This is safer than returning the mvar itself since a user can't accidentally put the mvar (which will dead-lock) or take the mvar (which when executed twice will dead-lock). The attached patch additionally rewrites the function to wait for a group of threads to complete. Instead of keeping a list of MVars, I use a counter (stored in a TVar) that counts the number of running threads. The counter is incremented when a thread if forked and decremented when it completes. Waiting for the group of threads to complete is accomplished by checking if the counter has reached 0 and if not retry the transaction. Regards, Bas [6126] http://hackage.haskell.org/trac/ghc/ticket/6126

1 0

Intersect by and union documentation in base
by Bram Neijt 27 May '12

27 May '12

Dear library maintainers, I've used both intersectBy and unionBy from the Base.List module. For intersectBy the documentation did not mention which element will be used when an element is in both lists. The attached patch adds a line to the documentation of intersectBy, where I think it makes sense to add this information. The unionBy documentaiton has the same kind of problem, however I did not patch that because I'm not sure whether this is part of the contract union whats to take on (I mean being deterministic in which list is the preferred source of elements). Please consider updating the documentation and feel free to contact me for more information if needed. Greetings, Bram

2 1

[PATCH] Fix typo in documentation of GHC.Exts.groupWith
by Simon Hengel 27 May '12

27 May '12

--- GHC/Exts.hs | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/GHC/Exts.hs b/GHC/Exts.hs index 0bf8f7f..8281895 100755 --- a/GHC/Exts.hs +++ b/GHC/Exts.hs @@ -102,7 +102,7 @@ sortWith :: Ord b => (a -> b) -> [a] -> [a] sortWith f = sortBy (\x y -> compare (f x) (f y)) -- | The 'groupWith' function uses the user supplied function which --- projects an element out of every list element in order to to first sort the +-- projects an element out of every list element in order to first sort the -- input list and then to form groups by equality on these projected elements {-# INLINE groupWith #-} groupWith :: Ord b => (a -> b) -> [a] -> [[a]] -- 1.7.5.4

2 1