November 2015 - Haskell-Cafe

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 16 Nov '15

16 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

Re: [Haskell-cafe] haskell-src-exts maintenance
by malcolm.wallace 16 Nov '15

16 Nov '15

We too have been waiting a long time for a refreshed release of HSE. If Matthew has already made the edits, and we are simply awaiting the package's release to Hackage, perhaps Matthew should go ahead make that release himself, and petition the Hackage admins to accept it, in view of the official maintainers' long silence? Regards, Malcolm On 12 Nov, 2015,at 05:37 PM, Matthew Pickering <matthewtpickering(a)gmail.com> wrote: Peter, Please can you do the release. I completed the work updating HSE several months ago, a much better version of HSE has been waiting on the master branch since then. I thank you for providing helpful review for the patches I submitted but since then I have sent three emails asking about the release. After the second you promised to do a release at the end of October but that never happened. It is a shame that the user's of HSE have had to live with many long standing bugs when they have been fixed for months. If you can not do it for whatever reason then please can you add me as a maintainer on hackage and the github repo so that users can get an updated version of HSE. Best wishes, Matt On Tue, Jul 28, 2015 at 11:35 PM, Peter A Jonsson <jonsson.peter.a(a)gmail.com> wrote: I’m not even going to bother to CC haskell-cafe since that will just bounce or go into a black hole. I exchanged a couple of mails with David (Lemmih) and my impression was that he was going to act upon some things but I didn’t follow up on that so there was probably some miscommunication between the two of us. I’ve merged some things and reviewed some patches. I agree with Neil that stable things should be merged and the yearly release of HSE should be made. I don’t want to rush things out through the door at any cost though—I believe HSE’s users are better served by something that is a strict improvement and contains more features than the last release compared to something that has even more features but is a bit shaky and requires a new major version of HSE in just a month or two which would force the client code to be re-tested and re-released. Best Wishes, Peter On 28 Jul 2015, at 17:49, Neil Mitchell <ndmitchell(a)gmail.com> wrote: As a very heavy HSE user (HLint and Hoogle), who has had a reasonably close working relationship with all of Niklas (my SoC mentor and my SoC mentee), Roman and Peter (a fellow supercompiler developer) and Matt (currently hacking on HLint), I thought I should weigh in. The current state of HSE is a little forlorn - there are 22 open pull requests, everything from reducing algorithm complexity (an accidental n^3), fixing the default encoding (should be UTF8) and lots of actual parser fixes. A lot of this is good stuff, and the high level of external contributions is a really good sign. But they need to be merged and reviewed, and it seems the bandwidth just isn't there at the moment. Given Matt's comments on the existing tickets, and the triage he's already performing on the repo, I have high hopes that Matt could provide a bit more of the time and attention. Peter, perhaps a co-maintainer would be good for a little while? If it's not soon then please could you add myself and Christian to the maintainers so that we can perform some short term maintenance. My immediate plan of action would be 1. Immediately cut a 1.17 release from the master branch as it contains much better parsing of lifted constructors which are becoming more prevalent. 2. Review and merge recent pull requests. 3. Update the parser as far as possible with missing features. 4. Release 1.18 with these improvements within 1 month. Awesome! Although as a preference I'd go for as much of 2 as you can in a couple of days before doing 1 - a lot of the patches are simple and valuable, and a 2 day wait isn't going to be too problematic. Thanks, Neil _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

2 1

The last decade: what has changed, was has stayed the same?
by Joachim Durchholz 16 Nov '15

16 Nov '15

Hi all, I used to be interested in Haskell roughly a decade ago, then life happened. Now that I'm setting up project work, I'm interested in what has been happening in the meantime. I read a bit on the usual pages, did a quick scan of the mailing list, didn't find out what the important questions of today are and what answers exist. Some ideas of relevant questions below. Feel free to pose and answer your own questions :-) After learning the bare language, how long does it take a competent programmer to become confident in the performance of his Haskell code? After learning the bare language, how long does it take a competent programmer to know when and when not to use strictness annotations/operators? I'm seeing a lot of typesystem golf happening. Is this teachable to the average competent programmer? Is it relevant to everyday programming such as business logic, database access, or webpage generation? (If no, for what programming endeavours is it relevant?) What's the status of debugging - I dimly remember a rough consensus that stack traces are hard to interpret in a meaningful way. (I know that debugging is far less important for a referentially transparent language than for others, but it would still be interesting.) What's the status of all the "boring stuff": - logging - profiling - dialog layout - input validation - database interaction - webpage generation, webflow - multi-tiered applications On the "instant to-do" side: What would a competent programmer need to do to become a competent Haskell programmer? (I suspect the usual set of toy projects will not work. Toy projects give you only so much mileage; in particular, you don't learn anything about what patterns will hold up for larger projects and what patterns won't scale.) Regards, Jo

2 2