News aggregator

Meetup - Calling all haskellers from Croatia

haskell-cafe - Thu, 07/10/2014 - 8:07pm
We've opened a meetup group for all haskellers from Croatia and someone suggested we should post info about it here as it might reach more interested people that way. Here's the link to the meetup group (please join): Sorry for the spam if this doesn't apply to you. -Deni _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >
Categories: Offsite Discussion

[ANN](and feedback request) unagi-chan: Fast and scalable concurrent queues for x86, with a Chan-like API

haskell-cafe - Thu, 07/10/2014 - 7:39pm
I'm happy to finally release unagi-chan, an implementation of high-performance concurrent FIFO queues that have an API very similar to Control.Concurrent.Chan. You can see benchmarks and documentation here: If you have a moment (especially if you're on a non-x86 architecture) please take 10 minutes and run the tests with: $ cabal configure --enable-tests $ cabal build $ time ./dist/build/test/test Thanks to Ryan Newton for helping answer some low-level questions about his atomic-primops package which provides the CAS and fetch-and-add implementations that are the core of unagi-chan. REQUEST FOR FEEDBACK: would anyone be interested in any functionality like the following: - concurrent builder for Text, something like: new :: IO (InTextChan , Lazy.Text) write :: String -> InTextChan -> IO () - something similar for ByteString (is there a class for types convertable to ByteString?) - concurrent Text and/or ByteSt
Categories: Offsite Discussion

ATX Haskell meetup/study groups happening this month!

Haskell on Reddit - Thu, 07/10/2014 - 4:46pm

Here in sunny Austin Texas we've spun up a Haskell meetup group, and if you're in the area, you should join! Specifically, we've set up a small meetup tomorrow as a training class to help people solidify and expand their Haskell knowledge.

We currently are having monthly meetups here with classical talks, and we're also planning of setting up monthly or biweekly study groups like the one tomorrow for people to talk and learn in a different setting. So the one tomorrow will hopefully be the first of many more to come.

Tomorrow the study group will be downtown at MakerSquare - and if you're in the area, you should come by! Brand new to Functional Programming? Don't have GHC installed? Don't even know what Haskell is? No matter - things will happen, people will learn things, and you should come by and learn how awesome it is and how awesome all of us are, and we'll help you as much as we can.

Next week we'll be having a meeting at Rackspace in North Austin, where we'll be talking about error handling in Haskell, and I'll probably talk about something and I have no idea what that will be yet (it'll be a secret).

We normally have a turnout of about 20 people for the meetings. But that's just because you haven't come and hung out yet. The meetings are typically open forum and rather lax. So you're encouraged to raise your hand or just speak up.

We also tend to go drink beers and talk into the night afterwords - with many riveting conversations, including subjects like (roughly in order of priority):

  • Tacos. Beer. Serious business.
  • Why is software so terrible?
  • How to achieve world domination in a purely-functional way?
  • Education and how to do that properly.
  • War stories (tears of joy/pain are encouraged)
  • Cloud computing (the half-dozen Rackspace employees love this one!)
  • Ask Austin (me, not the town) how some random GHC thing works.
  • Non-taco-related foods.

Also, a bajillion points go to Rackspace for giving us a great working space for our meetups so far and providing us with great pizza for the past several meetings.

submitted by aseipp
[link] [comment]
Categories: Incoming News

Edwin Brady: Resource-dependent Algebraic Effects

Planet Haskell - Thu, 07/10/2014 - 11:21am

A new draft paper, Resource-dependent Algebraic Effects, is available. Abstract:

There has been significant interest in recent months in finding new ways to implement composable and modular effectful programs using handlers of algebraic effects. In my own previous work, I have shown how an algebraic effect system (called “effects“) can be embedded directly in a dependently typed host language. Using dependent types ought to allow precise reasoning about programs; however, the reasoning capabilities of effects have been limited to simple state transitions which are known at compile-time. In this paper, I show how effects can be extended to support reasoning in the presence of run-time state transitions, where the result may depend on run-time information about resource usage (e.g. whether opening a file succeeded). I show how this can be used to build expressive APIs, and to specify and verify the behaviour of interactive, stateful programs. I illustrate the technique using a file handling API, and an interactive game.

I’ve just submitted this, although constructive comments and suggestions are still of course very welcome!

Categories: Offsite Blogs

Threading Argument vs Reader Monad

Haskell on Reddit - Thu, 07/10/2014 - 11:19am

I've been wondering about this for a little bit:

Q: When is it more convenient to use a Reader Monad as opposed to just threading an argument through your program?

I.e. what is the advantage of:

f :: String -> Reader Config SomeType -- vs g :: String -> Config -> SomeType

One advantage I've seen is that if you don't annotate your functions with type signatures and use the Reader Monad with type inference, you can change the type of the shared environment without having to update much code (except code that pulls out of the shared environment, but that can be factored out and shared as well). Is this the only advantage? The disadvantage to this approach, imo, is you lose the nice readability you get from explicit type signatures.

On the other hand, if you need to introduce a dependency, you can just thread it through your function via plain-old arguments. What do you lose with this? Is it that you must update all functions that depend on modified methods, and programming in a monadic style may avoid some of these explicit refactorings?

Perhaps using the Reader Monad becomes more handy in large code-bases?


PS - my apologies if I'm not articulating this well.

Edit: thank you everyone. The consensus as I understand it seems to be (upstream/downstream refer to a methods call graph):

  1. Reader monad allows environment-independent methods from having to manage the environment for downstream dependencies.
  2. Reader monad is safer (you cannot manipulate or change the environment in an upstream method)
  3. MonadReader class makes working with Reader monad nice .
submitted by aaronlevin
[link] [16 comments]
Categories: Incoming News

Parsing Python source code

Haskell on Reddit - Thu, 07/10/2014 - 11:01am

For my summer project, I’d like to learn Haskell by implementing a Python 3 interpreter. I’m evaluating options for parsing, specifically the whitespace sensitivity part. Either:

  • Alex + custom lexer pass to accommodate indent tracking + Happy (conventional approach)
  • Parsec + indents package

I started with Parsec, but got burned by it’s lexeme function eating newlines. Right now I'm using Alex + Happy, and wishing I had the help of idents. I’m more familiar with traditional yacc-esque LALR parser generators, so there's a comfort using them. (Since Python's grammar is LL, I believe it means Parsec is a viable option.)

Any advice on what to go with here?

submitted by mattygrocks
[link] [4 comments]
Categories: Incoming News

Help with performance of a sliding puzzle solver

Haskell on Reddit - Thu, 07/10/2014 - 10:13am

Hello, as a practice exercise I decided to code a sliding puzzle solver (like 8-puzzle or 15-puzzle). Now, the solution is there and it is working but the problem I face now is the runtime. I would like to request some help with optimising the solution (if at all possible). I'm interested to see what steps one could take to improve performance of their Haskell program.

My implementation can be found here:

Sample input file:

4 5 4 3 8 9 2 6 1 0 13 14 7 15 11 10 12

If you run it under the profiler you will see that the amount of data we generate is about 9Gb. And the "problematic" functions are manhattan and boardDistance. I'm currently clueless about how to tackle these functions to optimise them (if at all possible). Seeking for your help!


submitted by faorien
[link] [11 comments]
Categories: Incoming News

If you want to write PHP, learn Haskell

Haskell on Reddit - Thu, 07/10/2014 - 8:25am

Hi Timothy,

I’m xxxxx from Facebook’s recruiting team. I found your profile on Github and Haskellers and think that you could be a great match for Facebook.

We are currently looking for Senior Software Engineers to join our London office and work on products such as Search, Mobile Engineering, Developer Platform, Security, Site Integrity, etc.

Your passion for Haskell really caught my attention :)

Would you be interested in having a conversation about the opportunities at Facebook London that might be of interest to you?

If you are interested, let me know a day/time that suits and we can organise a time to talk.

Thanks, xxxxx

The funny thing, is I got an almost identical email from google a while back. These are all sent out as template letters.

Actually, I think that this isn't a great thing. This is zero barrier recruting. They didn't look at my code and chances are they'd stop being interested the second they saw my resume. I don't yet have enough experience working in a group to work as a senior engineer. I have about 12 hours work experience. It doesn't cost them anything to send out these emails en-mass. But it probably costs a lot of young developers time and stress trying to respond to them only to find later that the interest wasn't meant seriously.

submitted by timthelion
[link] [35 comments]
Categories: Incoming News

PEPM 2015: Call for papers

General haskell list - Thu, 07/10/2014 - 6:43am
PEPM 2015 Paper Submission Deadline: September 12 (FIRM) Note: deadline is significantly earlier than previous years. Hope to see you in Mumbai, India! ----------------------------- C A L L F O R P A P E R S ----------------------------- ======= PEPM 2015 =========== ACM SIGPLAN 2015 WORKSHOP ON PARTIAL EVALUATION AND PROGRAM MANIPULATION Tue-Wed, January 13-14, 2015, Mumbai, India, co-located with POPL'15 Sponsored by ACM SIGPLAN SCOPE The PEPM Symposium/Workshop series aims at bringing together researchers and practitioners working in the areas of program manipulation, partial evaluation, and program generation. PEPM focuses on techniques, theory, tools, and applications of analysis and manipulation of programs. The 2015 PEPM workshop will be based on a broad interpretation of semantics-based program manipulation and continue last years' successful effort to expand t
Categories: Incoming News

Review brainfuck interpreter in Haskell

Haskell on Reddit - Thu, 07/10/2014 - 6:08am

Please go through it and tell me anything that can be done more elegantly. Thanks in advance.

submitted by kmspriyatham
[link] [5 comments]
Categories: Incoming News

Hackage update, part 3

Haskell on Reddit - Thu, 07/10/2014 - 3:10am
Categories: Incoming News

Checking all interleavings of concurrent program - my first semi-serious Haskell project

Haskell on Reddit - Thu, 07/10/2014 - 1:30am

Link first: concurrency-simulator

Long-time lurker here. I've put together knowledge from several blog posts (especially from here, here and here) and made my first semi-serious Haskell project: concurrency simulator. You can define concurrent program using special monad and then you can run it in several ways: normally in IO, in IO with some additional logging, using predefined interleaving and then inspecting all possible interleavings. All interleavings mode is especially interesting, because it allows to exhaustively test program for bugs.

Generic comments and criticism are welcome, but I have also some specific questions, if you don't mind.

1) allRuns function uses list monad as base of monad transformer stack (I've abstracted away which exactly stack with ListAtBottom class). This is convenient, but also very slow. It allows easy enumeration of all possible interleavings, but doesn't allow any navigation in the tree of possible outcomes in search for goal (i. e deadlock). Better way would be inspecting tree of possible outcomes (at least one level ahead, using singleStep function, but possibly more), to prioritize search, but I honestly don't know how to do it, at least not without losing generality of allRuns type.

2) Another nice thing would be paralelizing allRuns function. There is some really stupid attempt to do it at the bottom of the file. Does anybody know about parallel implementations of list monad? Or should I give up list monad and use explicit sequence manipulation?

submitted by zarazek
[link] [2 comments]
Categories: Incoming News

Yesod Web Framework: RFC: New Data.Conduit.Process

Planet Haskell - Thu, 07/10/2014 - 1:15am

I've been working on a new iteration of the Data.Conduit.Process API over the past few days. The current API (provided by the process-conduit package), has some issues. So I'm starting over with a new API, and will be including this in conduit-extra's next release.

Before releasing, I'd like to get some feedback on the new API. I've put together a School of Haskell tutorial, which will ultimately become the real documentation for this module. It describes usage of the library, as well as why the library looks the way it does. You can view the source on the process branch of conduit.

In case anyone's wondering, the "well known bug" in waitForProcess may actually not be very well known yet. There's a race condition documented in the source code, but it's not nearly as narrow a window as implied there. For example, the following code will reliably throw an exception:

import System.Process import Control.Concurrent.Async main :: IO () main = do (_, _, _, ph) <- createProcess $ shell "sleep 1" let helper i = do ec <- waitForProcess ph print (i :: Int, ec) ((), ()) <- concurrently (helper 1) (helper 2) return ()

Thus the motivation for fixing the problem in Data.Conduit.Process. Thanks go to Michael Sloan for discovering the severity of this race condition. In fact, the bug he ran into, combined with a separate process-conduit bug I ran up against, were the impetus for me getting this library written now.

For the lazy, here's a copy of the content from School of Haskell:

NOTE: This tutorial documents a not-yet-released version of conduit-extra's Data.Conduit.Process module. Currently, that module name is provided by process-conduit, which provides a completely different API. This tutorial is present now for early feedback. If you'd like to experiment, this code is available on the process branch of the conduit repo.


Whenever you run an external process, there are four ways to interact with it post-creation:

  • Write to its standard input
  • Read from its standard output
  • Read from its standard error
  • Check its exit code

The standard System.Process module provides means for all of these interactions. However, there are some downsides with using them:

  • Many of the function in System.Process rely on lazy I/O.
  • There is a subtle race condition when checking for exit codes.
  • Dealing with Handles directly is relatively low-level.

Data.Conduit.Process provides a higher-level interface for these four interactions, based on conduit. It additionally leverages type classes to provide more static type safety than dealing directly with System.Process, as will be described below. The library is also designed to work with the wonderful async library, providing for easy, high-quality concurrency.

Note that providing general parameters for creating a process, such as its working directory or modified environment variables, are not addressed by this module; you should instead use the standard facilities from System.Process.

Synopsis{-# LANGUAGE OverloadedStrings #-} import Control.Applicative ((*>)) import Control.Concurrent.Async (Concurrently (..)) import Control.Concurrent.Async (Concurrently (..)) import Data.Conduit (await, yield, ($$), (=$)) import qualified Data.Conduit.Binary as CB import qualified Data.Conduit.List as CL import Data.Conduit.Process (ClosedStream (..), conduitProcess, proc, waitForConduitProcess) import System.IO (stdin) main :: IO () main = do putStrLn "Enter lines of data. I'll base64-encode it." putStrLn "Enter \"quit\" to exit." ((toProcess, close), fromProcess, ClosedStream, cph) <- conduitProcess (proc "base64" []) let input = CB.sourceHandle stdin $$ CB.lines =$ inputLoop =$ toProcess inputLoop = do mbs <- await case mbs of Nothing -> close Just "quit" -> close Just bs -> do yield bs inputLoop output = fromProcess $$ CL.mapM_ (\bs -> putStrLn $ "from process: " ++ show bs) ec <- runConcurrently $ Concurrently input *> Concurrently output *> Concurrently (waitForConduitProcess cph) putStrLn $ "Process exit code: " ++ show ecExit codes

There's a well documented corner case in waitForProcess whereby multiple calls can end up in a race condition, and therefore a deadlock. Data.Conduit.Process works around this issue by not providing direct access to a ProcessHandle. Instead, it wraps this with a ConduitProcessHandle, which uses an STM TMVar under the surface. This allows you to either poll to check if a process has exited, or block and wait for the process to exit. As a minimal example (ignore the streaming bits for now, they'll be explained shortly).

import Data.Conduit.Process main :: IO () main = do (Inherited, Inherited, Inherited, cph) <- conduitProcess (shell "sleep 2") -- non-blocking getConduitProcessExitCode cph >>= print -- blocking waitForConduitProcess cph >>= print

If you need direct access to the ProcessHandle (e.g., to terminate a process), you can use conduitProcessHandleRaw.


Now to the main event: streaming data. There are multiple ways you can interact with streams with an external process:

  • Let the child process inherit the stream from the parent process
  • Provide a pre-existing Handle.
  • Create a new Handle to allow more control of the interaction.

One downside of the System.Process API is that there is no static type safety to ensure that the std_out parameter in fact matches up with the value produced by createProcess for the standard output handle. To overcome this, Data.Conduit.Process makes use of type classes to represent the different ways to create a stream. This isn't entirely intuitive from the Haddocks, but once you see the concept used, it's easy to use yourself.

Inherited and ClosedStream

Let's start with an example of using the simplest instances of our typeclasses. Inherited says to inherit the Handle from the parent process, while ClosedStream says to close the stream to the child process. For example, the next snippet will inherit stdin and stdout from the parent process and close standard error.

import Data.Conduit.Process main :: IO () main = do putStrLn "Just wrapping cat. Use Ctrl-D to exit." (Inherited, Inherited, ClosedStream, cph) <- conduitProcess (shell "cat") waitForConduitProcess cph >>= print

Note that there's no way to send an EOF in School of Haskell, so the above active code will never terminate.


It would be pretty strange to have a library in conduit-extra that didn't provide some conduit capabilities. You can additionally get a Sink to be used to feed data into the process via standard input, and Sources for consuming standard output and error.

This next example reads standard input from the console, process standard output with a conduit, and closes standard error.

import Data.Conduit (($$)) import qualified Data.Conduit.List as CL import Data.Conduit.Process main :: IO () main = do putStrLn "Just wrapping cat. Use Ctrl-D to exit." (Inherited, src, ClosedStream, cph) <- conduitProcess (shell "cat") src $$ CL.mapM_ print waitForConduitProcess cph >>= print

Note that these Sources and Sinks will never close their Handles. This is done on purpose, to allow them to be used multiple times without accidentally closing their streams. In many cases, you'll need to close the streams manually, which brings us to our next section.

Conduit + close

Let's say we'd like to close our input stream whenever the user types in "quit". To do that, we need to get an action to close the standard input Handle. This is simple: instead of just returning a Source or Sink, we ask for a tuple of a Source/Sink together with an IO () action to close the handle.

{-# LANGUAGE OverloadedStrings #-} import Data.ByteString (ByteString) import Data.Conduit (Source, await, yield, ($$), ($=)) import qualified Data.Conduit.Binary as CB import Data.Conduit.Process import System.IO (stdin) userInput :: Source IO ByteString userInput = CB.sourceHandle stdin $= CB.lines $= loop where loop = do mbs <- await case mbs of Nothing -> return () Just "quit" -> return () Just bs -> do yield bs yield "\n" loop main :: IO () main = do putStrLn "Just wrapping cat. Type \"quit\" to exit." ((sink, close), Inherited, ClosedStream, cph) <- conduitProcess (shell "cat") userInput $$ sink close waitForConduitProcess cph >>= printUseProvidedHandle

Let's take a quick detour from our running example to talk about the last special type: UseProvidedHandle. This says to conduitProcess: use the example value of UseHandle provided in std_in/std_out/std_err. We can use this to redirect output directly to a file:

import Data.Conduit.Process import System.IO (withFile, IOMode (..)) main :: IO () main = do let fp = "date.txt" withFile fp WriteMode $ \h -> do (ClosedStream, UseProvidedHandle, ClosedStream, cph) <- conduitProcess (shell "date") { std_out = UseHandle h } waitForConduitProcess cph >>= print readFile fp >>= printUse with async

In our examples above, we only ever used a single Source or Sink at a time. There's a good reason for this: we can easily run into deadlocks if we don't properly handle concurrency. There are multiple ways to do this, but I'm going to strongly recommend using the async package, which handles many corner cases automatically. In particular, the Concurrently data type and its Applicative instance make it easy and safe to handle multiple streams at once.

Instead of duplicating it here, I'll ask the reader to please refer back to the synopsis example, which ties this all together with two threads for handling streams, and another thread which blocks waiting for the process to exit. That style of concurrency is very idiomatic usage of this library.

Categories: Offsite Blogs


haskell-cafe - Thu, 07/10/2014 - 12:52am
Hi cafe, I whipped up extensible-transformers ( this afternoon. The idea is to make Monad transformer code more like extensible-effects code ( Here's a sample: {-# LANGUAGE FlexibleContexts #-} module Main(main) where import Control.Monad.Trans.Flexible import Control.Monad.Trans.List import Control.Monad.Trans.State.Strict
Categories: Offsite Discussion

Taking over setlocale

haskell-cafe - Wed, 07/09/2014 - 10:33pm
Greetings, I would like to take over the setlocale package. Following the steps described on I need to state my intention on a public forum. The original author (Lukas Mai) published his package in the Public Domain. This would be fine, but the Author seems to be living in Germany. The problem with that is that in Germany an author is not allowed to give up his copyright in this way. This means the licensing of the package defaults to "All rights reserved", making the package undistributable. I already tried to contact the author about this problem, but he didn't respond in a week. This isn't a very long time, but I didn't get an answer on past attempts to contact him (this was at least a month, but probably more, ago). To solve this problem, I rewrote the setlocale binding with the same API under the BSD3-clause. PS: Please keep the CC to Lukas Mai and the debian-haskell list intact. Regards Sven _____________________________________________
Categories: Offsite Discussion