- Haskell-Cafe - Haskell.org

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

Type-level lazy bool operations
by Dmitry Olshansky 16 Nov '15

16 Nov '15

Hello, cafe! There are some type-level boolean operation (If, &&, ||, Not) in Data.Type.Bool. Are they lazy enough? I faced with problem and it seems that the reason is non-lazy "If". I.e. both (on-True and on-False) types are trying to be calculated. Does it work in this way really? Could it be changed? Then, looking into source I see such definition for (&&) -- | Type-level "and" type family a && b where 'False && a = 'False 'True && a = a a && 'False = 'False a && 'True = a a && a = a Why we need the last three rules? Does it mean that an order of type calculation is totaly undefined? Dmitry

2 1

wxHaskell can now be run multiple times in GHCi
by Henk-Jan van Tuyl 15 Nov '15

15 Nov '15

L.S., Good news for people who want to develop wxHaskell programs by experimenting in GHCi: wxHaskell programs can now be run multiple times in GHCi (GHC 7.10.2, 32 bit). Running a wxHaskell program in the 64 bit version of the interpreter results in the message: addDLL: could not load DLL This is caused by a GHC bug and is reported in GHC bug ticket 3242 [0], it should be solved in GHC 8.0.1 (The 32 bit GHCi crashes when exited, after running a wxHaskell program, but this is not a problem for application developers.) Regards, Henk-Jan van Tuyl [0] https://ghc.haskell.org/trac/ghc/ticket/3242 -- Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming --

1 0

Mono-whatever
by David Feuer 15 Nov '15

15 Nov '15

Does any package define a type like this? data X :: * -> k -> k -> * where X :: b -> X b t t So instance (MonoFoldable b, Element b ~ t) => Foldable (X b t) where foldMap f (X b) = ofoldMap f b

1 0

Daunting heap profile when using (<>)
by martin 14 Nov '15

14 Nov '15

Hello all, I have a Logger which produces log entries and a new version of itself newtype Logger evt dom log = Lgr {runLogger :: Timed evt -> dom -> (log, Logger evt dom log)} Loggers are used in a function like this runSim :: (Ord evt, Monoid log) => SimBehaviour evt dom log -> SimState evt dom log -> SimState evt dom log runSim (!lgr, !hdr, xtp) (!log,!dom,!evq) = case step of Nothing -> (log, dom, evq) -- end of simulation Just (newEvq, newDom, newHdr, newLgr, newLog) -> runSim (newLgr,newHdr,xtp) (newLog,newDom,newEvq) where -- check for end conditions or run handler step = do (evt, evts) <- H.view evq -- no more Events -> Nothing if xtp (evt,dom) then Nothing else let (evq', dom', hdr') = runHandler hdr evt dom (log',lgr') = runLogger lgr evt dom' -- <-- -- append new event and new log entries in return (evq'<>evts, dom', hdr', lgr', log'<>log) -- <-- I then wrote a function to combine two Loggers addLgr (lgr1) (lgr2) = Lgr lgr where lgr tev dom = let (log1', lgr1') = runLogger lgr1 tev dom (log2', lgr2') = runLogger lgr2 tev dom (!log') = log2' <> log1' -- x -- -- in (log2', addLgr lgr1' lgr2') in (log', addLgr lgr1' lgr2') When called a million times, this produces a heap profile which climbs steadily (with or without the stricness annotation in line x). When I omit the (<>) as in the commented line, the heap stays flat. My log is really just a list of strings and most of the time the loggers do not produce any output, i.e. they return an empty list. Am I on the right track, that this trouble is probably caused by laziness and that forcing strictness is the way to go? Could it be that this is because ! does not fully evaluate its argument, but just to WHNF? Or is there a more obvious reason, I just fail to see. Where to go from here?

2 5