May 2012 - Libraries - Haskell.org

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

transforming xhtml attributes
by Chris Dornan 11 May '12

11 May '12

Folks, I am proposing to extend the xhtml package slightly to better support attribute munging. Currently you would use (!) to add a bunch of attributes to an element, thus: b1 = button noHtml ! [name "go", value "go"] The problem, as pointed out by mistuke[1] is that there is no way to safely add attributes as this could result in an attribute being bound ambiguously and illegally [2] thus: b2 = b1 ! [value "oops"] Apparently this can lead Haddock to generate illegal (X)HTML [1]. My proposed solution is to add a new CHANGEATTRS class with the overloaded function: changeAttrs :: CHANGEATTRS a => a -> ([HtmlAttr] -> [HtmlAttr]) -> a and to export a function for analysing the (abstract) HtmlAttr type: htmlAttrPair :: HtmlAttr -> (String, String) CHANGEATTRS/changeAttrs/htmlAttrPair works just like ADDATTRS/(!) except that the attributes can be analysed and transformed. extend_name :: Html -> Html extend_name h = h `changeAttrs` map f where f a = case htmlAttrPair a of ("name",nm) -> name $ "foo_" ++ nm _ -> a Finally, I have an embarrassing confession to make -- I forgot that I should be getting the changes reviewed here -- even for such a modest widening of the API -- and have already put out 3000.2.1 with these additions onto Hackage! Comments and feedback welcome though, Chris [1] https://github.com/haskell/xhtml/issues/2 [2] http://www.w3.org/WAI/GL/WCAG20-TECHS/H94.html

1 0

Proposal: unify constant functors
by wren ng thornton 07 May '12

07 May '12

Hello all, I recently (re)noticed the following duplication: base:Control.Applicative newtype Const a b = Const { getConst :: a } instance Functor (Const m) where... instance Monoid m => Applicative (Const m) where... transformers:Data.Functor.Constant newtype Constant a b = Constant { getConstant :: a } instance Functor (Constant a) where... instance Foldable (Constant a) where... instance Traversable (Constant a) where... instance (Monoid a) => Applicative (Constant a) where... I don't see any reason for this redundancy. I propose we: (1) add the Foldable and Traversable instances to base, and (2) deprecate transformers:Data.Functor.Constant This will cause breakage to any orphan instances of Foldable/Traversable for Const, but that seems fine by me. Eventually we'll want to remove transformers:Data.Functor.Constant (or have it re-export the Const stuff from base:Control.Applicative); but that can be handled later. Deadline: 14 May 2012. -- Live well, ~wren

13 22

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

07 May '12

Hi, I've recently noticed unGetChan and isEmptyChan have been deprecated as a result of these two bug reports: http://hackage.haskell.org/trac/ghc/ticket/3527 http://hackage.haskell.org/trac/ghc/ticket/4154 I was working on an alternative implementation of concurrent channels (concurrent streams) to use as a building block for FRP and thought while I'm at it I'd have a go at fixing the problem with concurrent channels. I've attached the files for a reimplementation of concurrent channels, 2 implementations of lower-level concurrent queues, one that only supports non-blocking reads, and another that supports both blocking and non-blocking reads, and an implementation of concurrent streams. The reimplementation of concurrent channels is built on top of the blocking queue. The streams are built on top of the non-blocking queue and have Functor and Applicative instances. The reimplementation of concurrent channels passes the two tests in the bug reports above. I haven't run further tests though. The logic for how the channel operations are supposed to proceed is summarized in Chan.hs. Due to an extra lock this implementation is likely a bit slower than the old implementation. One assumption that has been made is that IORef reads and writes are atomic. In other words that if there are two or more concurrent writes to the same IORef, one of them will successfully write its data to it. I have not been able to find exact semantics of IORefs though I've asked in #haskell and others have suggested that the assumption is valid. Proposal: 1) split concurrent channels from base into a separate library of higher level concurrency primitives 2) add concurrent queues to the library of higher level concurrency primitives 3) replace concurrent channels with the new implementation based on concurrent queues 4) add concurrent streams to the library of higher level concurrency primitives I was in a bit of a rush to write this up and post the code after finding out that the new Haskell platform will be released this month though it seems unlikely this would go in at this point - probably for the best as the code hasn't been tested much. I'm also not sure if concurrent streams would be more appropriate on Hackage? Thoughts and comments appreciated. Deadline: 8th of June. Ivan

2 2