- Haskell-Cafe - Haskell.org

[ANN] New OpenCV Bindings
by Arjun Comar 29 Sep '13

29 Sep '13

Hi all, I've been hard at work on a new set of OpenCV bindings that will hopefully solve a lot of the shortcomings with previous attempts. An automatic header parser has been used to generate a full set of Haskell bindings for the C++ API, and I'm now working to create a pleasant Haskell API. The plan is to expose major functionality through pipes for two reasons: 1) OpenCV is not very referentially transparent, and so you're stuck in IO for anything non-trivial. Lazy IO is potentially problematic, and so immediate incorporation of a proper streaming library is probably best. 2) Computer vision algorithms are frequently expressed in terms of pipelines of functionality, and a pipes approach can provide a very natural API for expressing these algorithms. At this stage, I could very much use input from anyone who's interested in these bindings. I've got the basics of a library forming, but there's a ton to do and help in the form of pull requests are very very welcome. I could also use feedback on what's been done so far (especially criticisms) as well as feature requests. The current plan is to develop the pipes API for the core functionality. The plan is to provide the major functionality from core, highgui, imgproc, features2d, contrib, ml, flann, video, and objdetect as quickly as I can before trying to cover any of the more specialized parts of the API. The functions and types from these modules (baring a few major and important exceptions) are automatically translated into C wrappers and raw Haskell bindings. If there's sufficient interest in these raw bindings separately from the API I'm developing, I'll release them as a separate package on Hackage. I'm calling my project revelation for the moment because I'm bad at naming things and it was the best pun I could come up with. Github: www.github.com/arjuncomar/revelation Regards, Arjun

3 10

Proposal: new function for lifting
by Thiago Negri 29 Sep '13

29 Sep '13

Everybody is claiming that using lift is a bad thing. So, I come to remedy this problem. Stop lifting, start using shinny operators like this one: (^$) :: Monad m => m a -> (a -> b -> c) -> m b -> m c (^$) = flip liftM2 Then you can do wonderful stuff and you will never read the four-letter word in your code again: \> Just 42 ^$(+)$ Nothing Nothing \> Just 10 ^$(+)$ Just 20 Just 30 \> let add = (+) \> Just 30 ^$ add $ Just 12 Just 42

4 3

Fwd: [GSoC 2013] Porting Charts to Diagrams - Final Report
by Jan Bracker 28 Sep '13

28 Sep '13

Hello everybody, I am sorry to send this a second time. Someone hinted out that I would not reach everybody on the mailing list through the Google Groups address. I should have looked a bit more thoroughly. The Google Summer of Code 2013 is over! My project to port the charts [0] library to use diagrams [1] as an alternative to cairo [2] was a full success. The project goal [3,4] was to remove cairo as a dependency and replace it with a open backend API so different technologies can be used to render charts. This was mainly necessary, because cairo is hard to install on platforms like windows or mac. Aside of that it also makes charts more flexible and opens the doors for renderings charts in different contexts. We were successful. The cairo rendering code was completely removed from the chart library and replaced by a drawing API [5] that is backend independent. The cairo rendering backend, of course, is still there and now provided as the separate package Chart-cairo [6]. In addition we implemented a second backend based on the diagrams library. It is provided in Chart-diagrams [7]. To give some more detail on the development: The backend API is now based on a deep embedding of all drawing commands in the ChartBackend monad. The sequence of drawings commands resulting from this is then interpreted by a implementing backend. We use the operational package [9] to implement the deep embedding. Implementing the cairo backend was straightforward, because the backend API was developed with the cairo API in mind. Implementing the diagrams backend was some more work. Drawing on its own is not a problem but calculating text metrics is, because it requires to access the systems font rendering capabilities most of the time. Diagrams does not offer this access for several reasons (missing backend support, unclear how API would look, etc.). You can look at the diagrams-discuss mailing list for further information on this topic. We used the SVGFonts [10] library to render fonts, because of these issues. It is independent of the used backend and uses the SVGFonts format to render fonts and calculate their metrics. Like this fonts can be preloaded and metrics can be calculated on the fly. The only downside of this approach is that its performance is not to good, because we render each glyph as a path and because the math done in diagrams is not to fast either. At least when rendering to SVG files we could improve the performance by embedding fonts into the produced SVG and by that saving to insert each glyph as a path. The API to access this is not yet on hackage but the new version will be released soon. You can look at the GitHub repository [11] if you want to access it. Along with this development I also had the change to tackle some bugs and improve the diagrams-svg [12] and SVGFonts [10] code. Everybody who is interested in the details of the development process and see every bit of what was done can check the chart or diagrams mailing list. Both contain the progress reports of the project [8]. So have a look at charts [0] and see what it can do. We also have a nice little tutorial on how to use the new backends [13]. Greets Jan [0]: https://github.com/timbod7/haskell-chart/wiki [1]: http://projects.haskell.org/diagrams/ [2]: http://hackage.haskell.org/package/cairo [3]: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/jbracker… [4]: http://www.google-melange.com/gsoc/project/google/gsoc2013/jbracker/33001 [5]: http://hackage.haskell.org/packages/archive/Chart/1.0/doc/html/Graphics-Ren… [6]: http://hackage.haskell.org/package/Chart-cairo [7]: http://hackage.haskell.org/package/Chart-diagrams [8]: https://groups.google.com/d/topic/diagrams-discuss/S2nkxyxbtcY/discussion [9]: http://hackage.haskell.org/package/operational [10]: http://hackage.haskell.org/package/SVGFonts [11]: https://github.com/timbod7/haskell-chart/blob/master/chart-diagrams/Graphic… [12]: http://hackage.haskell.org/package/diagrams-svg [13]: https://github.com/timbod7/haskell-chart/wiki/How-to-use-backends

2 2

Munich Haskell Meeting, 2nd birthday
by Heinrich Hördegen 28 Sep '13

28 Sep '13

Dear all, I am pleased to announce that our monthly Haskell meeting is scheduled on Monday, 30th of September, 19h30 at Cafe Puck. If you plan to join, please click the button at: http://www.haskell-munich.de/dates Our monthly meetings started on Thu, 29 Sept 2011, so this will be over two years now! With hope to coninue in this nice and friendly sprit, Heinrich

1 0

Re: [Haskell-cafe] Proposal: new function for lifting
by Nick Vanderweit 27 Sep '13

27 Sep '13

Sorry for sending this twice; I didn't reply to the list initially. I thought people [1] were generally talking about lift from Control.Monad.Trans: class MonadTrans t where lift :: Monad m => m a -> t m a The idea being that lifting through a monad stack feels tedious. The proposed solution is to use instances to do the lifting for you, like in mtl. So we've got instances like: MonadState s m => MonadState s (ReaderT r m) Which let you automatically lift get/put/modify up a stack, without doing any work. This is different from liftM*, which are about applying a pure function to monadic arguments. This can be done quite nicely with (<$>) and (<*>) from Data.Functor and Control.Applicative, respectively. Your first example can be written: (+) <$> (Just 42) <*> Nothing Nick [1] http://blog.ezyang.com/2013/09/if-youre-using-lift-youre-doing-it-wrong-pro…

1 0

Non-termination using Free Monads and Data Types a la Carte
by Alexander Solla 27 Sep '13

27 Sep '13

I am trying to use a data types a la carte approach to define a free monad for templating purposes. I am using Edward Kmett's free package, and a module implementing data types a la carte's injections, modelled on the IOSpec Types module. I have written a few combinators, but I am stuck. My program keeps diverging, and I don't see why. Consider: math :: Math :<: f => MathExpr a -> Free f () blank :: f :<: (Textual :+: Math) => Free f () -> Free (Blank k f) () equals :: Free (Math :+: (Blank L Math)) () -> Free (Math :+: (Blank R Math)) () -> Free Equation () The intention is that a blank takes in a properly typed abstract syntax tree and tags it with "blank k", so that the parsers/renderers do the "right thing" (when I get around to implementing them) The composition (blank . math) has the type: blank . math :: ( f :<: (Textual :+: Math) , Math :<: f ) => MathExpr a -> Free (Blank k f) () Notice that f must be simultaneously less than or equal to the join of Textual and Math, and greater than or equal to Math. So the only possibility for f is Math. (I realize the compiler can't infer this without more work on my part) The problem happens when I try to evaluate (using scoped type signatures to get around my comment above): test :: Free Equation () test = (hoistFree (inj :: Blank 'L Math a -> (Math :+: Blank 'L Math) a) . blank . (math :: MathExpr x -> Free Math ()) $ "hi" ) `equals` (math $ "world") which apparently loops, pegging my CPU at 100%. The computation prints its result as: Free (Equation (Free (DirectSum {unDirectSum = Right at which point the value is truncated and GHCi quits. So it apparently gets as far as figuring out that the first argument to equals is in the latter part of the direct sum, but it doesn't seem t be able to compute blank. Relatively minimal source is available at: monad: http://lpaste.net/93471 data types a la carte: http://lpaste.net/93472 All my functions are total and I don't see a bottom here, but I was never any good at fixed point combinators. Any ideas?

1 0

[ANNOUNCE] cereal-0.4.0.0
by Trevor Elliott 27 Sep '13

27 Sep '13

Hi Everyone, I'm happy to announce the newest release of the cereal[1] binary serialization library. This includes a number of bug fixes, as well as instances of Serialize for the newtypes defined in Data.Monoid. Happy hacking! --trevor [1] http://hackage.haskell.org/package/cereal-0.4.0.0

1 0

Proposal: RankedInstances
by Wvv 26 Sep '13

26 Sep '13

The main power of Haskell is on instances. But Haskell instances system work fine with lower number of instances (rare instances). But we want hight density of instances! If we wish to have more selective instances we use `OverlappingInstances` (which are desined in a poor way) and if we still have too many instances we use `IncoherentInstances`. ~~`RankedInstances` extension ~~ I suggest simple `RankedInstances` extension. We use it (!)before OverlappingInstances (it must include `RankedInstances`), and in many cases instead of. This extension is easy to implement and it give us a lot of new possibilities and instruments. Now the system of instances is flat, and compiler takes all of them and check if only 1 match. If it is not(less or more than) - compiler trow an error. I suggest to add rankings, so compiler * compiler set N=0 * took all N-ranked instances and ** try to find only one match instance. *** If it found 1 - this is RESULT: needed instance, *** If it found many instances - still throw an error ******* (then we use `OverlappingInstances` to resolve this) *** If compiler found NO instances, compiler set N=N+1 and repeat * If N=MaxRank and still no matches compiler throw an error ~~How to add a rank~~ I suggest next grammar: {-# LANGUAGE RankedInstances #-} instance rank 1. C a => D a where ... instance C2 a => E a where ... <<==>> instance rank 0. C2 a => E a where ... So, all written instances(without ranking) are 0-ranked instances. Backward compatibility => without -XRankedInstances all instances with rank n, where n >0 - are not exported ~Example~ 1) instance rank 1. C Int a where ... -- (A) instance C a Bool where ... -- (B) rank 0 1+) instance rank 1. C Int a where ... -- (A) instance rank 1. C a Bool where ... -- (B) instance C Int Bool where ... -- (C) rank 0 2) instance rank 1. C Int [a] where ... -- (C) instance C Int [Int] where ... -- (D) As we see, all instances are unambiguous! ~~ Rank Scale~~ It is for discussion, I see this like: 0 - default 1 ..9 - user free (without fear to overlap with devs instances) 10 .. 14 - Generic 15 .. - superclass' instances ~~ Higher Rank instances~~ We don't need to use `default` inside of class: instance rank 10. (Generic a, GToJSON (Rep a)) => ToJSON a where toJSON = genericToJSON defaultOptions We could add superclass' instances now, something like these: instance rank 15. Monad m => Applicative m where pure = return (<*>) = ap instance rank 16. Monad m => Functor m where fmap = liftM instance rank 17. Applicative m => Functor m where fmap f x = pure f <*> x ~~Inherit mechanism~~ What do if we want to use any proposed instance, not in the rank order ? For example we have data, which is Monad and Applicative, but not a Functor. We'll use automatically "instance rank 16. Monad m => Functor m", but not "instance rank 17. Applicative m => Functor m" . But we wish to use the last one. We need to create a new instance and inherit the behavior of needed instance data D a .... instance Monad D where ... instance Applicative D where ... instance rank 1. Functor D inherit (D ~ m) instance Applicative m => Functor m foo = ... fmap So, in this case we'll use `fmap` as Applicative Functor. Inherit mechanism defaulting : instance C a => D a where ... <<==>> instance C a => D a inherit (a ~ b) class D b where ~~ "As" pattern in RankedInstances~~ Now we add "as" pattern and rewrite both of our instances: instance rank 17. Applicative m => ApFunctor@Functor m where fmap f x = pure f <*> x instance ApFunctor D --by the way 0-ranked Wow!!! It is simple, safe and looks nicer! ~~Partly Applied Instances~~ We describe a situation when we write a child class and want automatically get access to parent's classes. But sometimes we need to use already defined parent classes to describe children classes We CANNOT do next: instance rank 20. (Functor m, Applicative m) => Monad m where ma >> mb = (fmap (const id) ma) `apply` mb instance rank 21. Applicative m => Monad m where ma >> mb = (pure (const id) <*> ma) `apply` mb Because if we define data D a ... instance Functor D ... instance Applicative D ... D a >>= D b -- this will compiler, but we have no full applied MonadInstance How to resolve this? I suggest to add one reserved world "newclass" (as an analog of newtype) --instance (Functor m, Applicative m) => FAMonad@Monad m where newclass (Functor m, Applicative m) => FAMonad@Monad m where ma >> mb = (fmap (const id) ma) `apply` mb --instance Applicative m => AMonad@Monad m where newclass (Applicative m) => AMonad@Monad m where ma >> mb = (pure (const id) <*> ma) `apply` mb The "newclass" is just an instance, but guarded - compiler did count it when it try to match So, now next throw an error: D a >>= D b And we have an ability to write more precisely instance AMonad H where instance FAMonad K where ~~~BIG Example~~~~ Let try to divide "class (Eq a)=>Ord a" to both: ORIGINAL ONE: class (Eq a) => Ord a where compare :: a -> a -> Ordering ... compare x y = if x == y then EQ else if x <= y then LT else GT Proposed one (it is just an example, not a "real" proposal): class Ord' a where ........... compare x y = if x < y then LT else if x > y then GT else EQ -- without Eq it is a last choice newclass (Eq a) => Ord@Ord' a where compare x y = if x == y then EQ else if x <= y then LT else GT So now we have both Ord' a for nonEQ data and for Eq data. And this has a backward compatibility! -- View this message in context: http://haskell.1045720.n5.nabble.com/Proposal-RankedInstances-tp5737152.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

1 0

Looking for numbers to support using haskell
by Mike Meyer 26 Sep '13

26 Sep '13

Hi all, I'm looking for articles that provide some technical support for why Haskell rocks. Not just cheerleading, but something with a bit of real information in it - a comparison of code snippets in multiple languages, or the results of a study on programmer productivity (given all the noise and heat on the topic of type checking, surely there's a study somewhere that actually provides light as well), etc. Basically, I'd love things that would turn into an elevator pitch of "I can show you how to be X times more productive than you are using Y", and then the article provides the evidence to support that claim. Thanks, Mike

5 5

Why superclass' instances are bad idea?
by Wvv 26 Sep '13

26 Sep '13

I suggest to add superclass' instances into libraries. http://ghc.haskell.org/trac/ghc/ticket/8348 In brief, we could write next: >{-# LANGUAGE FlexibleInstances #-} >{-# LANGUAGE UndecidableInstances #-} > >instance Monad m => Applicative m where > pure = return > (<*>) = ap > >instance Monad m => Functor m where > fmap = liftM > >instance Monad m => Bind m where > (>>-) = flip (>>=) > B.join = M.join this code is valid! I've already defined 3 "superclassses" for Monad: Functor, Applicative and Bind! Similar idea said Edward Kmett in 2010 (founded by monoidal) ( http://stackoverflow.com/questions/3213490/how-do-i-write-if-typeclass-a-th… ) And he said "but effectively what this instance is saying is that every Applicative should be derived by first finding an instance for Monad, and then dispatching to it. So while it would have the intention of saying that every Monad is Applicative (by the way the implication-like => reads) what it actually says is that every Applicative is a Monad, because having an instance head 't' matches any type. In many ways, the syntax for 'instance' and 'class' definitions is backwards." Why? I don't understand. Not every Applicative is a Monad, but every Monad is Applicative -- View this message in context: http://haskell.1045720.n5.nabble.com/Why-superclass-instances-are-bad-idea-… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

2 2