News aggregator

transformers appears to benefit from more inline

haskell-cafe - Sun, 01/24/2016 - 8:21pm
Hi everyone, I've recently been playing with a little mtl-like approach to streaming data, whereby I have a single type class - MonadYield - which can yield data, and then I use various implementations of this type class to implement operations. My usual approach to this is to implement this by newtyping around appropriate "off-the-shelf" monad transformers from the transformers library, but I found that this incurs a significant performance penalty. I've tried to put some fairly extensive benchmarks in place, which you can find at In that repository is a file that describes how I have been performing these benchmarks. The benchmarks are defined over a common interface that each implementation of MonadYield exports. The benchmarks are defined in "Benchmarks.hs", and the three implementations are "Transformers.hs" (using transformers from GHC), "TransformersInline.hs" (using transformers-ocharles from that repository, which has many more INLINE pragmas) and
Categories: Offsite Discussion

Parsing Bitstreams with haskell

Haskell on Reddit - Sun, 01/24/2016 - 2:32pm
<!-- SC_OFF --><div class="md"><p>I'm very new to haskell and I am at the point where I would like to do little projects to learn more. My professional career consists of programming audio decoder / encoders in C,so I thought a good start would be parsing Bitstreams. I found the Bytestream examples in &quot;learn you a haskell&quot; but there does not seem to be support for bit fields that are smaller than 8 bits. I found a couple of packages in, but wasn't able to identify which is the right one for this task. Any ideas?</p> </div><!-- SC_ON --> submitted by
Categories: Incoming News

Freer play with effects

Haskell on Reddit - Sun, 01/24/2016 - 11:44am
submitted by
Categories: Incoming News

Free play, part two

Haskell on Reddit - Sun, 01/24/2016 - 8:53am
submitted by
Categories: Incoming News

When are MVars better than STM?

haskell-cafe - Sun, 01/24/2016 - 8:46am
Hi friends, Using Criterion, I have been running benchmarks to measure the relative performance of STM and MVars for some simple transactions that I expect will be typical in my application. I am using GHC 7.10.2 and libraries as at Stackage LTS 3.2. I have found that STM is faster than MVars in all my benchmarks, without exception. This seems to go against accepted wisdom [1][2][3]. I have not included my source code here to save space, but if you suspect that I am using MVars incorrectly, just say so and I will post my source code separately. I have two questions: 1. When are MVars faster than STM? If the answer is "never", then when are MVars "better" than STM? (Choose your own definition of "better".) 2. When given two capabilities (+RTS -N2), MVars are suddenly an order of magnitude slower than with just one capability. Why? For those who want details: My benchmark forks four Haskell threads. Each thread repeats a transaction that increments a shared counter many, many times. These transactions
Categories: Offsite Discussion

Webdriver scroll down?

Haskell on Reddit - Sun, 01/24/2016 - 5:30am
<!-- SC_OFF --><div class="md"><p>Hi,</p> <p>Can anyone tell me how to scroll down a web page with webdriver?</p> </div><!-- SC_ON --> submitted by
Categories: Incoming News

[ANN] nano-erl

haskell-cafe - Sat, 01/23/2016 - 11:39pm
I've written a tiny library for Erlang-style actor semantics in Haskell: It's fast, and meant to be a lightweight abstraction that's easy to integrate with existing code. Enjoy! Tom
Categories: Offsite Discussion

Servant or other library for a largish API?

Haskell on Reddit - Sat, 01/23/2016 - 11:18pm
<!-- SC_OFF --><div class="md"><p>I'm relatively new Haskell and certainly some of the type system extensions that Servant employs. I am converting a webapp with about 30 endpoints to Servant. Since with Servant, the API declaration is a type, I imagine that will become quite a sophisticated type. Will the compiler become unbearably slow with such a large type? Or is that not an issue? </p> <p>I am happy to consider other libraries which might be suitable for a web application of this size. Servant looks great, but I was also looking at Spock. Any feedback is much appreciated. </p> </div><!-- SC_ON --> submitted by
Categories: Incoming News

Maybe/Either vs exceptions [Video]

Haskell on Reddit - Sat, 01/23/2016 - 9:38pm
submitted by
Categories: Incoming News

Stack users: multiple executables in one cabal file, or multiple packages in stack.yaml?

Haskell on Reddit - Sat, 01/23/2016 - 9:04pm
<!-- SC_OFF --><div class="md"><p>Hi <a href="/r/haskell">/r/haskell</a>!</p> <p>At work (Originate – insert plug here for and its jobs listings) I'm organizing a rather large project. Right now our incremental build times are high, on the order of minutes. We have a project with one cabal file; in the cabal file is one library target and lots of executable targets. The only package listed in our stack.yaml is <code>'.'</code>. When I <code>stack build</code> for a one-file change in one of the executable targets, a small but still noticeable amount of time is spent processing each target.</p> <p>I've noticed that some projects using stack list multiple packages in stack.yaml: <code>project</code>, <code>project-subproject</code>, <code>project-other-subproject</code>. Inside each <code>project</code> is a .cabal file with one target. Do you guys have preferences toward one structure vs. the other? I'm definitely looking to improve build times. We're doing some obvious things toward that goal: compiling with <code>--fast</code> while in development mode and making sure files with large Template Haskell usages are never unnecessarily compiled. Would switching to a multiple-package layout improve incremental build times? Presumably <code>stack build</code> wouldn't need to process all the other targets (unless they were dependencies).</p> <p>Maybe we should all just buy beefier laptops. :)</p> <p>And, even if build times don't improve, do you guys notice aesthetic or other advantages to having multiple packages? Or maybe there's a third option I haven't considered?</p> <p>I've been googling around for prior research but I had trouble finding people in a situation similar to mine.</p> </div><!-- SC_ON --> submitted by
Categories: Incoming News

Magnus Therning: Freer play with effects

Planet Haskell - Sat, 01/23/2016 - 6:00pm

In the previous posts on my playing with free I got stuck at combining APIs. I recalled reading a paper on extensible effects as an alternatve to monad transformers. I have to admit to not having finished the paper, and not quite understanding the part I did read. When looking it up again I found that the work had continued and that there is a paper on more extensible effects. (I got to it via

A quick search of Hackage revealed the package extensible-effects with an implementation of the ideas, including the stuff in the latter paper. So, what would the examples from my previous posts look like using extensible effects?


The examples require a few extensions and modules:

{-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeOperators #-}


import Control.Eff import Control.Eff.Lift import Control.Eff.Operational import Data.Typeable Just an API

This part was greatly helped by the fact that there is a example in extensible-effects.

I start with defining the SimpleFile API using GADTs

data SimpleFileAPI a where LoadFile :: FilePath -> SimpleFileAPI String SaveFile :: FilePath -> String -> SimpleFileAPI ()

The usage of the constructors need to be wrapped up in singleton. To remember that I create two convenience functions

loadFile :: Member (Program SimpleFileAPI) r => FilePath -> Eff r String loadFile = singleton . LoadFile saveFile :: Member (Program SimpleFileAPI) r => FilePath -> String -> Eff r () saveFile fp = singleton . SaveFile fp

For withSimpleFile I only have to modify the type

withSimpleFile :: Member (Program SimpleFileAPI) r => (String -> String) -> FilePath -> Eff r () withSimpleFile f fp = do d <- loadFile fp let result = f d saveFile (fp ++ "_new") result

Now for the gut of it, the interpreter.

runSimpleFile :: (Member (Lift IO) r, SetMember Lift (Lift IO) r) => Eff (Program SimpleFileAPI :> r) a -> Eff r a runSimpleFile = runProgram f where f :: (Member (Lift IO) r, SetMember Lift (Lift IO) r) => SimpleFileAPI a -> Eff r a f (LoadFile fp) = lift $ readFile fp f (SaveFile fp s) = lift $ writeFile fp s

Runnnig it is fairly simple after this

> :! cat test.txt Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec a diam lectus. Sed sit amet ipsum mauris. Maecenas congue ligula ac quam viverra nec consectetur ante hendrerit. > runLift $ runSimpleFile $ withSimpleFile (map toUpper) "test.txt" > :! cat test.txt_new LOREM IPSUM DOLOR SIT AMET, CONSECTETUR ADIPISCING ELIT. DONEC A DIAM LECTUS. SED SIT AMET IPSUM MAURIS. MAECENAS CONGUE LIGULA AC QUAM VIVERRA NEC CONSECTETUR ANTE HENDRERIT.

Now, that was pretty easy. It looks almost exactly like when using Free, only without the Functor instance and rather more complicated types.

Combining two APIs

Now I get to the stuff that I didn’t manage to do using Free; combining two different APIs.

I start with defining another API. This one is truly a play example, sorry for that, but it doesn’t really matter. The type with convenience function looks like this

data StdIoAPI a where WriteStrLn :: String -> StdIoAPI () writeStrLn :: Member (Program StdIoAPI) r => String -> Eff r () writeStrLn = singleton . WriteStrLn

The interpreter then is straight forward

runStdIo :: (Member (Lift IO) r, SetMember Lift (Lift IO) r) => Eff (Program StdIoAPI :> r) a -> Eff r a runStdIo = runProgram f where f :: (Member (Lift IO) r, SetMember Lift (Lift IO) r) => StdIoAPI a -> Eff r a f (WriteStrLn s) = lift $ putStrLn s

Now I just need a program that combines the two APIs

verboseWithSimpleFile :: (Member (Program StdIoAPI) r, Member (Program SimpleFileAPI) r) => (String -> String) -> String -> Eff r () verboseWithSimpleFile f fp = writeStrLn ("verboseWithSimpleFile on " ++ fp) >> withSimpleFile f fp

That type is surprisingly clear I find, albeit a bit on the long side. Running it is just a matter of combining runStdIo and runSimpleFile.

> :! cat test.txt Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec a diam lectus. Sed sit amet ipsum mauris. Maecenas congue ligula ac quam viverra nec consectetur ante hendrerit. > runLift $ runSimpleFile $ runStdIo $ verboseWithSimpleFile (map toUpper) "test.txt" verboseWithSimpleFile on test.txt > :! cat test.txt_new LOREM IPSUM DOLOR SIT AMET, CONSECTETUR ADIPISCING ELIT. DONEC A DIAM LECTUS. SED SIT AMET IPSUM MAURIS. MAECENAS CONGUE LIGULA AC QUAM VIVERRA NEC CONSECTETUR ANTE HENDRERIT.

Oh, and it doesn’t matter in what order the interpreters are run!

At this point I got really excited about Eff because now it’s obvious that I’ll be able to write the logging “decorator”, in fact it’s clear that it’ll be rather simple too.

The logging

As before I start with a data type and a convenience function

data LoggerAPI a where Log :: String -> LoggerAPI () logStr :: Member (Program LoggerAPI) r => String -> Eff r () logStr = singleton . Log

For the decorating I can make use of the fact that APIs can be combined like I did above. That is, I don’t need to bother with any coproduct (Sum) or anything like that, I can simply just push in a call to logStr before each use of SimpleFileAPI

logSimpleFileOp :: (Member (Program SimpleFileAPI) r, Member (Program LoggerAPI) r) => SimpleFileAPI a -> Eff r a logSimpleFileOp op@(LoadFile fp) = logStr ("LoadFile " ++ fp) *> singleton op logSimpleFileOp op@(SaveFile fp _) = logStr ("SaveFile " ++ fp) *> singleton op

Of course an interpreter is needed as well

runLogger :: (Member (Lift IO) r, SetMember Lift (Lift IO) r) => Eff (Program LoggerAPI :> r) a -> Eff r a runLogger = runProgram f where f :: (Member (Lift IO) r, SetMember Lift (Lift IO) r) => LoggerAPI a -> Eff r a f (Log s) = lift $ putStrLn s

Running is, once again, a matter of stacking interpreters

> :! cat test.txt Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec a diam lectus. Sed sit amet ipsum mauris. Maecenas congue ligula ac quam viverra nec consectetur ante hendrerit. > runLift $ runLogger $ runSimpleFile $ runProgram logSimpleFileOp $ withSimpleFile (map toUpper) "test.txt" LoadFile test.txt SaveFile test.txt_new > :! cat test.txt_new LOREM IPSUM DOLOR SIT AMET, CONSECTETUR ADIPISCING ELIT. DONEC A DIAM LECTUS. SED SIT AMET IPSUM MAURIS. MAECENAS CONGUE LIGULA AC QUAM VIVERRA NEC CONSECTETUR ANTE HENDRERIT. Closing thoughts

With Eff I’ve pretty much arrived where I wanted, I can

  • define APIs of operations in a simple way (simpler than when using Free even).
  • write a definitional interpreter for the operations.
  • combine two different APIs in the same function.
  • translate from one API to another (or even to a set of other APIs).

On top, I can do this without having to write a ridiculous amount of code.

I’m sure there are drawbacks as well. There’s a mention of some of them in the paper. However, for my typical uses of Haskell I haven’t read anything that would be a deal breaker.

Categories: Offsite Blogs

Haskell code snippets for sqlite access for an NLP project

Haskell on Reddit - Sat, 01/23/2016 - 12:49pm
<!-- SC_OFF --><div class="md"><p>I am working on a Haskell natural language processing (NLP) relational database interface. Here are snippets of impure code to access sqlite that I needed for a prototype: <a href=""></a> This blog also contains some of my general opinions on Haskell development and hopefully the code will save someone a little bit of time.</p> </div><!-- SC_ON --> submitted by
Categories: Incoming News

Typesafe request/response?

Haskell on Reddit - Sat, 01/23/2016 - 12:08pm
<!-- SC_OFF --><div class="md"><p>I just came up with this pattern allowing typesafe request/response queries:</p> <pre><code>class RequestPair a b where request :: (RequestPair a b) =&gt; a -&gt; IO b request = undefined data GetUserIdByNameReq = GetUserIdByNameReq T.Text T.Text data GetUserIdByNameRes = GetUserIdByNameRes (Maybe UserId) instance RequestPair GetUserIdByNameReq GetUserIdByNameRes f :: IO (Maybe UserId) f = do GetUserIdByNameRes t &lt;- request (GetUserIdByNameReq undefined undefined) return t </code></pre> <p>The pattern is pretty basic, so I'm wondering whether it has been done elsewhere/better already?</p> </div><!-- SC_ON --> submitted by
Categories: Incoming News

Help with Reader monad

Haskell on Reddit - Sat, 01/23/2016 - 11:44am
<!-- SC_OFF --><div class="md"><p>I'm reading LYAH and I'm on the chapter describing the Reader monad, and the author give's this implementation:</p> <pre><code>instance Monad ((-&gt;) r) where return x = \_ -&gt; x h &gt;&gt;= f = \w -&gt; f (h w) w </code></pre> <p>I'm a little bit fuzzy on how this works. I've understood monads up to this point but now I'm a bit stuck. If he had used an example with the (&gt;&gt;=) in action in this example, I think I would have been able to understand, but instead <strong>do</strong> notation is used and that doesn't help me. Can someone implement ((-&gt;) r) and &gt;&gt;= in a way I can understand?</p> </div><!-- SC_ON --> submitted by
Categories: Incoming News

Does this exist in base?

Haskell on Reddit - Sat, 01/23/2016 - 9:53am
<!-- SC_OFF --><div class="md"><p>In some work I've done with records and corecords, I've found a newtype that I occassionally need when I want a record of functors that all operate over the same type. It looks like this:</p> <pre><code>newtype Flip a f = Flip { getFlip :: f a } </code></pre> <p>Does this already exist somewhere in <code>base</code> or in a commonly used library?</p> <p>Just in case anyone wonders what I'm using this for, it's something like this:</p> <pre><code>import Data.Vinyl myRec :: Rec (Flip Char) '[Maybe, Either String, Vector] myRec = Flip (Just 'a') :&amp; Flip (Left &quot;hey&quot;) :&amp; Flip (...) :&amp; RNil </code></pre> <p>I'm not actually using those functors, but that should at least sort of illustrate why I need <code>Flip</code>.</p> </div><!-- SC_ON --> submitted by
Categories: Incoming News

Can I use gloss on Android?

Haskell on Reddit - Sat, 01/23/2016 - 8:35am
submitted by
Categories: Incoming News

Cartesian product of lists

Haskell on Reddit - Sat, 01/23/2016 - 7:50am
submitted by
Categories: Incoming News

Haskell as a gradually typed dynamic language

Haskell on Reddit - Fri, 01/22/2016 - 10:59pm
submitted by
Categories: Incoming News

Richard Eisenberg: Haskell as a gradually typed dynamic language

Planet Haskell - Fri, 01/22/2016 - 9:38pm

I spent a few days this week at POPL (one day too short due to a massive blizzard currently pounding Philadelphia). As always at conferences, I had a great time and left full of new ideas.

This time, I sat in on a series of talks on gradual typing. Forgive me as I’m nowhere near an expert on gradual typing, but I took away this gist: with a gradual typing system, a type-checker does the best it can to assign static types; anything it can’t do is deferred to runtime in a dynamic type check.

As I nearly always do when considering a type system concept, I thought about how this might apply to Haskell. And I realized with a start that Haskell is only a stone’s throw away from a very spiffy gradually typed dynamic language! Let’s explore how this is the case.

(Disclaimer: I have no plans to implement any idea in this post. I also apologize, specifically, if I’m misusing the term “gradual typing”, which I’m not deeply versed in. This is all meant to be a bit tongue-in-cheek, though I think there’s a proper good idea in all of this.)

First, I wish to address a common fallacy about an existing feature in GHC:

Deferred type errors do not make Haskell a dynamic language

Recent versions of GHC come with a flag -fdefer-type-errors. (Naturally, this feature comes with its own published paper from ICFP’12.) With this flag enabled, type errors become warnings. When you try to run the code that contains a type error, you get a runtime exception. To wit:

> {-# OPTIONS_GHC -fdefer-type-errors #-} > module GradualHaskell where > > import Data.Typeable > > ex1 = not 'x'

Compiling produces

/Users/rae/work/blog/011-dynamic/post.lhs:32:13: warning: • Couldn't match expected type ‘Bool’ with actual type ‘Char’ • In the first argument of ‘not’, namely ‘'x'’ In the expression: not 'x' In an equation for ‘ex1’: ex1 = not 'x'

Running produces

*** Exception: /Users/rae/work/blog/011-dynamic/post.lhs:32:13: error: • Couldn't match expected type ‘Bool’ with actual type ‘Char’ • In the first argument of ‘not’, namely ‘'x'’ In the expression: not 'x' In an equation for ‘ex1’: ex1 = not 'x' (deferred type error)

What’s nice about deferred type errors is that they let you compile a program even with errors. You can then test the type-correct parts of your program while you’re still developing the type-incorrect parts.

However, deferred type errors don’t make Haskell a dynamic language.


> silly :: a -> b > silly True = False > silly False = "Howdy!" > silly 'x' = 42

This, of course, compiles with lots of warnings. But you can’t successfully call silly, even at one of the values matched against. Running silly True produces a runtime type error. This is not what one would expect in a dynamic language, where silly True is perfectly False. The problem in Haskell is that we have no way to know if the type silly is called at is really Bool: all types are erased. All deferred type errors do is to take the normal compile-time type errors and stuff them into thunks that get evaluated when you force the ill-typed expression. Haskell still never does a runtime type check.

Preserving type information to runtime

The way to make Haskell into a proper dynamic language must be to retain type information to runtime. But we already have a way of doing runtime type checks: Typeable and friends.

The constraint Typeable a means that we know a’s type at runtime. The Typeable interface (from Data.Typeable) includes, for example, the function

cast :: (Typeable a, Typeable b) => a -> Maybe b

which does a runtime type equality test and, if the test succeeds, casts an expression’s type.

As of GHC 7.10, all statically-known types are Typeable. (Saying deriving Typeable is a no-op.) But type variables might still have a type unrecoverable at runtime.

So, all of this adds up to an interesting idea. I propose a new language extension -XDynamicTypes with two effects:

  1. All type variables automatically get a Typeable constraint.
  2. The type-checker behaves quite like it does with -fdefer-type-errors, but instead of putting an unconditional type error in an expression, it does a runtime type check. If the check succeeds, the expression evaluates normally; otherwise, a runtime error is thrown.

Change (1), coupled with the fact that all non-variable types are already Typeable, means that all types are known at runtime. Then, change (2) enabled runtime typing. Under this scenario, my silly function above would elaborate to

> forceCast :: (Typeable a, Typeable b) => a -> b > forceCast x = case cast x of > Just y -> y > Nothing -> error "type error" -- could even print the types if we wanted > > notSilly :: (Typeable a, Typeable b) => a -> b > notSilly true | Just True <- cast true = forceCast False > notSilly false | Just False <- cast false = forceCast "Howdy!" > notSilly x | Just 'x' <- cast x = forceCast (42 :: Int)

This definition works just fine. It does do a lot of casting, though. That’s because of silly’s very general type, a -> b, which is necessary due to the differing types of silly’s equations. However, if all the equations of a function have the same type, then the function is inferred with a precise type, and no casting is necessary. Indeed, in a program that is type-correct without -XDynamicTypes, no runtime checks would ever take place.

This idea seems to give you get the flexibility of dynamic types with the speed of static types (if your program is statically type-correct). And this general model seems to fit exactly in the space of possibilities of gradual type systems.

I’ve heard it said that Haskell is the best imperative programming language. Could it also become the best dynamic language?

Categories: Offsite Blogs

question on the design of protohaskell (in Write Youa Haskell)

haskell-cafe - Fri, 01/22/2016 - 9:38pm
I know this part has been left incomplete when Stephen got a real job, but I have a question. In, compiler steps are piped together using the Kleisli (>=>) operator, presumably the one from Control.Monad. they also return some flavour of AST (typically Syn.Module or Core.Module). Assuming that the >=> is the one from Control.Monad, what is the purpose of this returned value (all the steps are in a compilerMonad and presumably would have to update the state w/ the new AST anyhow)? Or is the intention to have a special >=> that also updates the state (but I wouldn't know how to deal w/ Syn.Core vs Core.Module) I would understand some form of phantom type to ensure that compilation steps are in the right order, but as it is I'm puzzled. Anybody has some insight? Thanks, Maurizio _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >
Categories: Offsite Discussion