- Haskell-Cafe - Haskell.org

Call For Presentations: Compose 2016, New York, Feb 4-5
by Gershom B 18 Nov '15

18 Nov '15

Compose is a conference for typed functional programmers, focused specifically on Haskell, OCaml, F#, and related technologies. It will be held in New York on Thursday and Friday, Feb 4-5, 2016. Registration will be open shortly. http://www.composeconference.org/ To get a sense of Compose, you can check out the great talks from the 2015 conference: http://www.composeconference.org/2015/summary/ Below is our call for presentations. We recognize the deadline is tight, so feel free to submit proposals and ideas on the less-polished side. http://www.composeconference.org/2016/cfp/ * * * The audience for Compose is Haskell, OCaml, F#, or SML developers who are looking to increase their skills or learn new technologies and libraries. Presentations should be aimed at teaching or introducing new ideas or tools. We are also interested in presentations aiming at taking complex concepts, such as program derivation, and putting them into productive use. However proposals on anything that you suspect our audience may find interesting are welcome. The following are some of the types of talks we would welcome: Library/Tool Talks — Exploring the uses of a powerful toolkit or library, be it for parsing, testing, data access and analysis, or anything else. Production Systems — Experience reports on deploying functional techniques in real systems; insights revealed, mistakes made, lessons learned. Theory made Practical — Just because it’s locked away in papers doesn’t mean it’s hard! Accessible lectures on classic results and why they matter to us today. Such talks can include simply introducing the principles of a field of research so as to help the audience read up on it in the future; from abstract machines to program derivation to branch-and-bound algorithms, the sky’s the limit. We also welcome proposals for more formal tutorials. Tutorials should be aimed at a smaller audience of beginner-to-novice understanding, and ideally include hands-on exercises. The due date for submissions is December 14, 2015. We will send out notice of acceptance by December 24th. We prefer that submissions be via the EasyChair website (https://easychair.org/conferences/?conf=compose2016) Please suggest a title, and describe the topic you intend to speak on. Talks can be either 30 or 45 minutes, please indicate how much time you would prefer to take. Additional information may be included on both your expertise and the interesting elements of your topic, going on what might be included in a public abstract. Furthermore, if your abstract doesn't feel "final"—don't worry! We'll work with you to polish it up. If you want to discuss your proposal(s) before submitting, or to further nail down what you intend to speak on, please feel free to contact us at info(a)composeconference.org. We're happy to work with you, even if you are a new or inexperienced speaker, to help your talk be great. * * * Diversity We would like to put an emphasis on soliciting a diverse set of speakers - anything you can do to distribute information about this CFP and encourage submissions from under-represented groups would be greatly appreciated. We welcome your contributions and encourage you to apply! Best, Gershom

1 0

reactive-banana project examples
by Michael Litchard 18 Nov '15

18 Nov '15

Could I get some pointers to projects using reactive-banana. I'm looking for projects that have code testing their Behaviors.

1 0

Re: [Haskell-cafe] turn off "thread blocked indefinitely in an STM transaction"?
by Johannes Waldmann 17 Nov '15

17 Nov '15

myThreadId >>= newStablePtr ; atomically retry Yes, that works. Thanks.

1 0

Re: [Haskell-cafe] turn off "thread blocked indefinitely in an STM transaction"?
by Johannes Waldmann 17 Nov '15

17 Nov '15

Ah, neat. I get the idea. But does it work here? import Control.Concurrent.STM import Foreign.StablePtr main = atomically retry >>= newStablePtr ghc -threaded -rtsopts -O2 sp.hs ./sp +RTS -N sp: thread blocked indefinitely in an STM transaction - J.

2 1

turn off "thread blocked indefinitely in an STM transaction"?
by Johannes Waldmann 17 Nov '15

17 Nov '15

I find the following mildly annoying: Prelude> import Control.Concurrent.STM Prelude Control.Concurrent.STM> atomically retry *** Exception: thread blocked indefinitely in an STM transaction Is there a way to not raise this exception, and block the thread? I don't see this behaviour (raising the exception) mentioned in the API docs nor in the defining paper (Composable memory transactions, PPoPP'05) that is referenced there. I understand it might come in handy for debugging, but sometimes (e.g., for teaching) I might really want a transaction that never commits. For instance, I am forkIO'ing some worker threads and the main program really should do absolutely nothing. So I thought I could just block the main thread. I can make some work-around with forM [1..n] $ \ p -> ( if p < n then void . forkIO else id ) $ forever $ do but that feels clumsy (since asymmetric). - J.W.

2 1

the last mile in haskell performance
by Alberto G. Corona 17 Nov '15

17 Nov '15

Looking at this: https://downloads.haskell.org/~ghc/6.12.3/docs/html/users_guide/primitives.… It seems that it is impossible to manage data in Haskell within a core without L1 cache faults. Except for unboxed arrays of primitive types. Since it is impossible to have unboxed arrays of user-defined types. Am I right? This is definitively very bad for tasks that are inherently single threaded and in general for the image of Haskell as a practical language. I have more to say about that, but I would like to know first if I´m right and second If there is some idea to going on to permit user defined boxed datatypes. Or if there is some low level trick for having it using foreign call and unsafeCoerce in some way, I know that the language ATS has unboxing a la carte.... -- Alberto.

9 14

Streaming a Conduit into a lazy list
by Jules Bean 17 Nov '15

17 Nov '15

Conduits seem like a popular and useful way to compose operations which consume and produce streams at various speeds. I hadn't used them before, so apologies for any obvious mistakes below. Conduits have lots of power in terms of how you can interleave monadic effects with the streaming; but I found that I had a stream with no effects at all and I wanted to convert it back into haskells more simplistic representation, lazy lists. This is probably a well-known trick, but I couldn't find how to do this from googling, so here is the solution I found in case it helps someone else: > {-# LANGUAGE DeriveDataTypeable, FlexibleContexts #-} > module Main where > > import Data.Conduit > import Control.Monad.Catch > import Control.Monad.Trans.Resource > import Control.Monad.Writer > import Control.Monad.Identity > import qualified Data.Conduit.List as CL > import Data.Typeable > > source123Error :: Monad m => Source m Int > source123Error = do > yield 1 > yield 2 > yield 3 > error "error" A source which produces some data and then hangs, to test lazy production. One solution which doesn't work is CL.consume (as its own docs say) - and instead this happens: *Main> :t runIdentity (source123Error $$ CL.consume) runIdentity (source123Error $$ CL.consume) :: [Int] *Main> runIdentity (source123Error $$ CL.consume) *** Exception: error But what we can do instead is push the data out via the Writer monad: > tellEverything :: MonadWriter [a] m => Sink a m () > tellEverything = awaitForever (\x -> tell [x]) *Main> :t source123Error $$ tellEverything source123Error $$ tellEverything :: MonadWriter [Int] m => m () *Main> snd $ runWriter (source123Error $$ tellEverything) [1,2,3*** Exception: error Success! A lazily produced list. If your output is of any size - and depending on the compositions pattern in your code - it may be much faster to use this version: > tellEveryEndo :: MonadWriter (Endo [a]) m => Sink a m () > tellEveryEndo = awaitForever (\x -> tell (Endo (x:))) *Main> ($[]) . appEndo . snd . runWriter $ (source123Error $$ tellOne) [1,2,3*** Exception: error I found a further case where the Conduit I was trying to run was pure but had a 'MonadThrow' constraint. You can use the same approach here, using the ExceptionT transformer to satisfy the MonadThrow constraint. > data MyError = MyError deriving (Show,Typeable) > instance Exception MyError > > source123Throw :: MonadThrow m => Source m Int > source123Throw = do > yield 1 > yield 2 > yield 3 > throwM MyError *Main Control.Monad.Except Control.Monad.Trans.Resource> snd . runWriter . runExceptionT $ (source123Error $$ tellEverything) [1,2,3*** Exception: error *Main Control.Monad.Except Control.Monad.Trans.Resource> snd . runWriter . runExceptionT $ (source123Throw $$ tellEverything) [1,2,3] An aside: I tried to measure the speed difference between the list-mappend and Endo-mappend approaches with the following code. count2N uses a binary-tree shaped recursion so it should be fairly bad for list-mappend with lots of long lists on the left. > count2N :: Monad m => Int -> Source m Int > count2N 0 = yield 0 > count2N n = count2N (n-1) >> count2N (n-1) > speedTest1 = print . length . snd . runWriter $ (count2N 24 $$ tellEverything) > speedTest2 = print . length . ($[]) . appEndo . snd . runWriter $ (count2N 24 $$ tellEveryEndo) With -O or -O2 I measure no speed difference between these, they both take a bit over 2 seconds. With no optimisation flag, speedTest2 is slower, 17 seconds vs 11 seconds. I'm quite surprised the Endo version isn't faster, it seems like something is rewriting those list appends? Cheers, Jules

2 7

Darcs vs Git
by Geraldus 17 Nov '15

17 Nov '15

Hi friends! I love Haskell very much. So, I'm very interested in using Darcs. Is there some documentation explaining diffrences between Darcs and Git. Is there something that makes Darcs more robust rathen that Git. Does Darcs have some Emacs support (something like `magit`)? And one other question. Currently, I have no collaborators and use Git majorly myself to have version control, e.g. to revert some bad code, to have a nice log with code diffs and comments, and etc. But in future I will need something like GitHub for collaboration, is there a good solution for Darcs' hub already?

10 28

model checking for (subset of) concurrent Haskell?
by Johannes Waldmann 17 Nov '15

17 Nov '15

For model checking concurrent and distributed imperative programs, there's the Promela language, and the Spin model checker ( http://spinroot.com ) than can explore/enumerate a finite state space of a system and decide validity of LTL formulae. Is there something similar for Haskell models of concurrency? Ideally, some subset of Haskell (containing enough of Control.Concurrent.*) as an alternative for Promela. It should even be possible to put the model checking in an alternative implementation of respective monad (STM, IO for MVars) so the whole thing is an embedded DSL. somewhat related: this project is about a verified model checker: https://cava.in.tum.de/ (ML code generated from Isabelle) but my interest is in model-checking concurrent programs in functional notation. - J.W.

3 2

New Functional Programming Job Opportunities
by Functional Jobs 17 Nov '15

17 Nov '15

Here are some functional programming job opportunities that were posted recently: Haskell Developer (ON SITE) at CJ Affiliate by Conversant https://functionaljobs.com/jobs/8867-haskell-developer-on-site-at-cj-affili… Software Engineer - Functional Programmer - Erlang at Change Healthcare https://functionaljobs.com/jobs/8866-software-engineer-functional-programme… Cheers, Sean Murphy FunctionalJobs.com

1 0