- Libraries - Haskell.org

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

hackage vector-space-opengl
by Nikolay Orlyuk 21 May '12

21 May '12

Hello First of all I'd like to say that I like vector-space and vector-space-opengl is something that I'd like to use together with OpenGL. So while using that library I found some things that can be useful for others, I think. While looking into OpenGL/TH.hs I found that it quite incomplete and I understand why. That suggestion at stackoverflow results in a bit boilerplate code: deriveScalar, deriveScalarAdditiveGroup, deriveScalarVectorSpace, deriveScalarAffineSpace :: [Name] -> Q [Dec] deriveScalar ts = concat <$> forM decls (\qf -> qf ts) where decls = [ deriveScalarAdditiveGroup , deriveScalarVectorSpace , deriveScalarAffineSpace , deriveScalarInnerSpace ] deriveScalarVectorSpace ts = concat <$> mapM f ts where f tn = do t <- [t| $(conT tn) |] vs <- [t| VectorSpace |] (AppT (ConT s) _) <- [t| Scalar () |] -- dummy type to extract Scalar name (VarE h) <- [e| (*^) |] -- refer to actual (*^) from VectorSpace e <- [e| (*) |] -- (*) from Num return [ InstanceD [] (AppT vs t) [ TySynInstD s [t] t, ValD (VarP h) (NormalB e) [] ]] It's kinda partially checked and partially constructed. BTW, rather than depending on OpenGL its better to use Graphics.Rendering.OpenGL.Raw I think. Also there is types GLclampd and GLclampf (I suspect that they somehow related with OpenCL). While scalar types doesn't differ whether they are absolute whether they are not. Data.Tensor makes difference between Vertex and Vector. I suspect that made especially for this case: instance AffineSpace a => AffineSpace (Vertex2 a) where type Diff (Vertex2 a) = Vector2 (Diff a) I.e. Diff Vertex shouldn't be Vertex and Vertex a should not belong to AdditiveGroup If anyone knows how to walk through the whole module in monad Q that might bring more power to this library. I.e. walk through OpenGL.Raw and make declarations for all its scalar types. Thank you

2 2

Protocol Buffers 2.0.7
by Chris Kuklewicz 19 May '12

19 May '12

I have returned from the shadows of the intenet to maintain some packages! Version 2.0.7 of protocol-buffers (3 packages) has been uploaded to hackage. This makes it compile with ghc-7.4.1 and handle missing package names better. Thanks to everyone who sent email and patches, including Nathan Howell, Alexey Khudyakov, Howard B. Golden, Bryan O'Sullivan, Michael Stone, Daniel Rebelo de Oliveira, Paul Graphov, Tsurann, Sergei Trofimovich, Yitzchak Gale. The usual hackage links: http://hackage.haskell.org/package/hprotoc http://hackage.haskell.org/package/protocol-buffers-descriptor http://hackage.haskell.org/package/protocol-buffers And the darcs repo is at: http://code.haskell.org/protocol-buffers/ Q: What is protocol-buffers? A: It is a Haskell version of Google's protocol buffer wire protocol, see http://code.google.com/p/protobuf/ for a full description. Q: What does the hprotoc executable do? A: It convers "protocol-buffer descriptor files" into Haskell code to implement those data messages. Q: What does the protocol-buffers library do? A: It is the runtime API for using the binary protocol, serializing and deserializing the data types generated by hprotoc. Q: What is the protocol-buffers-descriptor library do? A: It is the support library for parsing "protocol-buffer descriptor files" into data structures. Most of this code is generated by hprotoc from a "protocol-buffer descriptor file" for "protocol-buffer descriptor files". Yes, it had to be bootstrapped. -- Dr. Chris Kuklewicz

1 0

Re: Safe Haskell at the export symbol granularity?
by Ryan Newton 17 May '12

17 May '12

Thanks David. I'm glad to see it was discussed in the wiki. (Btw, my 2 cents is that I like the comment pragmas more than new keywords.) The issue that I think doesn't make it into the wiki is of splitting, not modules, but* type-classes*. That's where I think it becomes a more serious issue. Do you think a symbol-level Safe Haskell would be able to distinguish one method of a type class as unsafe, while the others are safe? -Ryan P.S. In my two examples -- There's only one "Acc" type and Accelerate's "fold" can pretty easily be moved into an .Unsafe module, though it breaks the one-giant-module-for-the-whole-programming-model thing it has going now. In the Par example on the other hand type classes are used to abstract over different implementations, so that's where we run into the safe/unsafe factoring problem.

3 3

parallel containers dependency
by Edward Kmett 16 May '12

16 May '12

Would it be possible to relax the upper bound on parallel's dependency on containers to permit the use of 0.5? I was able to adjust about 20-30 of my packages to support the new containers with no change, right up until I ran into packages that use or transitively use parallel, and now I'm stuck. -Edward

2 1

Re: Proposal: To add 2 new lower-level concurrency constructs and rebuild Concurrent.Chan using them
by Ivan Tomac 16 May '12

16 May '12

Just had a few hours of sleep and think perhaps I sent that email out too soon. I forgot what my original intention was and just ended up submitting a proposal. The original question I had was what would be the best way to proceed with something like this? Have it submitted as a patch for Control.Concurrent.Chan with the concurrent queues added in? Or put it up on Hackage? Fixing concurrent channels and submitting this at all was sort of an afterthought but it just made sense to build them on top of the queues. Maybe Hackage is a better place for this until it's better tested in any case. Ivan

3 3

Safe Haskell at the export symbol granularity?
by Ryan Newton 14 May '12

14 May '12

Separate from whether or not we actually want this -- is it feasible? Here's my situation. When working on parallel programming libraries in Haskell there are very often unsafe operations one wants to do within an otherwise pure model. For example, Accelerate currently violates safe haskell because it trusts the user to provide an associative function to parallel "fold". No associativity, no referential transparency. The solution is to put fold in a separate namespace and mark that module as Unsafe. Likewise for certain monad-par operations that are unsafe. But this factoring can have a serious impact. Not only are extra modules required, but extra type classes as well. For example, if Accelerate is ever refactored for "Safe Haskell" then the following ParAccelerate type class probably should be as well: https://github.com/simonmar/monad-par/blob/5cc656bc45dc473d7a185ec99bb15619… I.e. ParAccelerate & ParAccelerateUnsafe for the "unsafeHybrid" operation. But this starts to be death by a thousand organizational factorings! - The package, abstract-par-accelerate, is already factored out from abstract-par just to avoid an unnecessary Accelerate dependency (which used to mean CUDA errors). (And *another* factoring is possibly warranted for whether or not the module depends on accelerate-io.) - The file would be separate to mark it as Safe Haskell. - The type class ParAccelerateUnsafe would be separate so as to put it in a separate file. What's a possible solution? If, in addition to "Safe" and "Unsafe" modules, there were "Partially Safe" modules, which exported a mix of safe and unsafe identifiers, then this could all be much cleaner. The simple rule is that any reference whatsoever to an unsafe identifier disqualifies the client code. For example, in the above ParAccelerate type class we would mark the unsafeHybrid binding with something like {-# UNSAFE unsafeHybrid #-}. We wouldn't even have to factor it out of the type class. Likewise, Accelerate could mark "fold" as unsafe (providing safe variants as well) without introducing module namespace bloat and confusion. What do you think? -Ryan

1 0

On the Haskell Platform
by Heinrich Apfelmus 13 May '12

13 May '12

Dear list, I have written a package, reactive-banana-wx, which seems to be quite enticing to Haskell beginners. It's an implementation of the fabled functional reactive programming (FRP), so it's natural that people want to play around with it to see what it is all about. I imagine that the latest parallelism packages also serve a similar audience. Of course, to play around with a package, you have to be able to install it, hopefully painlessly. As the maintainer, I have adopted the following principles as they appeared sound to me: 1. My package installs and works without any hitch on the latest Haskell Platform. This is easier said than done, because one of my dependencies is wxHaskell, which tends to have hitches at times. Occasionally, I restrict the version number to a specific, older wxHaskell version that I know to be bug free. In other words, the idea is that a complete Haskell beginner will be able to install my package with the standard setup even if he knows nothing about the Haskell ecosystem. 2. If the user has a setup that doesn't fit the dependencies I prescribe, then I expect him to change the version constraints himself (and hopefully tell me whether it works.) The idea is that having a non-standard setup is an indication that the user is no longer a beginner, so I can expect him/her to know how to change version constraints. With these principles in mind, imagine my surprise, then, to discover that the "Haskell Platform" on Ubuntu 12.04 includes GHC 7.4.1 http://packages.ubuntu.com/precise/haskell-platform Clearly, this must be a fake Haskell Platform, because the latest real Haskell Platform is still at GHC 7.0.4 at the time of this writing. Unfortunately, my principle 1 is now rendered moot. I don't quite know what to do. I understand that there is a need to get the latest GHC into the standard setup, but creating a "fake" Haskell Platform seems like a mistake to me, as it contradicts the use case "complete Haskell beginner" I described above. Not to mention that I'm stuck with the "real" Haskell Platform on Mac OS X and would have to manage separate cabal installations if I want to thoroughly test my package for all compiler versions. Or is it my principles that need to change? Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

5 6