- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] translation between two flavors of lexically-scoped type variables
by oleg＠okmij.org 07 Jul '12

07 Jul '12

Kangyuan Niu wrote: > Aren't both Haskell and SML translatable into System F, from which > type-lambda is directly taken? The fact that both Haskell and SML are translatable to System F does not imply that Haskell and SML are just as expressive as System F. Although SML (and now OCaml) does have what looks like a type-lambda, the occurrences of that type lambda are greatly restricted. It may only come at the beginning of a polymorphic definition (it cannot occur in an argument, for example). > data Ap = forall a. Ap [a] ([a] -> Int) > Why isn't it possible to write something like: > > fun 'a revap (Ap (xs : 'a list) f) = f ys > where > ys :: 'a list > ys = reverse xs > > in SML? This looks like a polymorphic function: an expression of the form /\a.<body> has the type forall a. <type>. However, the Haskell function > revap :: Ap -> Int > revap (Ap (xs :: [a]) f) = f ys > where > ys :: [a] > ys = reverse xs you meant to emulate is not polymorphic. Both Ap and Int are concrete types. Therefore, your SML code cannot correspond to the Haskell code. That does not mean we can't use SML-style type variables (which must be forall-bound) with existentials. We have to write the elimination principle for existentials explicitly {-# LANGUAGE ExistentialQuantification, RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} data Ap = forall a. Ap [a] ([a] -> Int) -- Elimination principle deconAp :: Ap -> (forall a. [a] -> ([a] -> Int) -> w) -> w deconAp (Ap xs f) k = k xs f revap :: Ap -> Int revap ap = deconAp ap revap' revap' :: forall a. [a] -> ([a] -> Int) -> Int revap' xs f = f ys where ys :: [a] ys = reverse xs Incidentally, GHC now uses SML-like design for type variables. However, there is a special exception for existentials. Please see 7.8.7.4. Pattern type signatures of the GHC user manual. The entire section 7.8.7 is worth reading.

2 2

Parameterized constraints
by Emil Axelsson 07 Jul '12

07 Jul '12

Hi! The `constraints` package provides ways to manipulate objects of kind `Constraint`. I need the same kind of manipulation, except that I need to work with objects of kind `* -> Constraint`. I.e. I need parameterized constraints that can be applied to different types. BTW, is there a standard term for things of kind `* -> Constraint`? I have a type family type family Constr (f :: * -> *) :: * -> Constraint which returns a parameterized constraint with the property that any value of type `f a` fulfills the constraint `Constr f a`. Since the constraint can be stronger than needed, I need something similar to `:-` from `constraints`, except it should operate on parameterized constraints. I have implemented the stuff I need (see below), but my question is if it's possible to do this with the `constraints` package directly (e.g. using `Forall`). I'm afraid I can't see how. Here is what I've come up with so far: -- Instead of (c1,c2) class (c1 a, c2 a) => (c1 :/\: c2) a instance (c1 a, c2 a) => (c1 :/\: c2) a -- Instead of (:-) type sub :< sup = forall a . Dict (sup a) -> Dict (sub a) -- Instead of weaken1 weak1 :: c1 :< (c1 :/\: c2) weak1 Dict = Dict weak2 :: c2 :< (c1 :/\: c2) weak2 Dict = Dict Thanks! -- / Emil

1 0

ANNOUNCE: husk-scheme, release 3.5.6
by Justin Ethier 07 Jul '12

07 Jul '12

I would like to announce the release of husk-scheme 3.5.6, a Scheme extension language and stand-alone interpreter/compiler that I have been developing. husk implements most of the Scheme R5RS standard<http://www.schemers.org/Documents/Standards/R5RS/HTML/>including advanced features such as continuations, hygienic macros, and a full numeric tower. husk has been an ongoing project for over a year now, but this is the first announcement on the mailing list so feedback is very welcome. Hackage: http://hackage.haskell.org/package/husk-scheme Homepage: http://justinethier.github.com/husk-scheme Change Log: https://github.com/justinethier/husk-scheme/blob/master/ChangeLog.markdown Issues and Enhancement Requests: https://github.com/justinethier/husk-scheme/issues Thanks, Justin

1 0

vector, alignment and SIMD through FFI
by Nicolas Trangez 06 Jul '12

06 Jul '12

Hello Cafe, Recently I've been playing with the implementation of an algorithm, for which we already have highly-optimized implementations available (in plain C/C++ as well as OCaml with calls to C through FFI). The algorithm works on buffers/arrays/vectors/whatever you want to call it, which needs to be combined in certain ways. This can be highly optimized by using SIMD instructions (like the ones provides by several SSE versions). I'd like to get a to Haskell version which is comparable in efficiency as the existing versions, whilst remaining as 'functional' as possible. I don't mind jumping into some low-level C glue and FFI (using ccall or custom primops), but this should be limited. Currently I have something working (still highly unoptimized) using (unboxed) vectors from the vector package, using mutable versions within a well-contained ST environment in some places. One hot zone of the current version is combining several vectors, and the performance of this operation could be greatly improved by using SIMD instructions. There's one catch though: when using these, memory should be aligned on certain boundaries (16 byte in this case). First and foremost, to be able to pass my vectors to some C functions, I should change my code into using Storable vectors (which should be fine, I guess I can expect similar performance characteristics?). I couldn't find any information on alignment guarantees of these vectors though... Which is how I get to my question: are there any such guarantees? If not, are there any pointers to how to proceed with this? I guess tracking alignment at the type level should be the goal, you can find some code trying to explain my reasoning up to now at the end of this email. I have some issues with this: - I'd need to re-implement almost all vector operations, which seems stupid. - It doesn't actually work right now ;-) - It'd be nice to be able to encode 'compatible' alignment: as an example, a 16 byte aligned buffer is also 8 byte aligned... I hope the above explains somewhat my goal. Any thoughts & help on this would be very welcome! Thanks, Nicolas module Data.Vector.SIMD ( -- ... ) where import qualified Data.Vector.Storable as SV import Foreign.Storable (Storable, sizeOf) import Foreign.Ptr (Ptr, FunPtr) import Foreign.ForeignPtr (ForeignPtr, newForeignPtr) import System.IO.Unsafe (unsafePerformIO) class Alignment a where alignment :: a -> Int data A8Byte instance Alignment A8Byte where alignment _ = 8 data A16Byte instance Alignment A16Byte where alignment _ = 16 newtype Alignment a => SIMDVector a b = V (SV.Vector b) replicate :: (Alignment a, Storable b) => a -> Int -> b -> SIMDVector a b replicate a n b = V v where ptr = unsafePerformIO $ do v <- _mm_malloc n (alignment a) -- memset etc return v v = SV.unsafeFromForeignPtr0 ptr n -- These are 2 _stub versions of the procedures since xmminstr.h (or mm_malloc.h -- when using GCC) contains them as inline procedures which are not available -- as-is in a library. There should be some C module which exports -- _mm_malloc_stub and _mm_free_stub, which simply includes xmminstr.h and calls -- the underlying procedures. foreign import ccall "_mm_malloc_stub" _mm_malloc_stub :: Int -> Int -> IO (Ptr a) foreign import ccall "_mm_free_stub" _mm_free_stub :: FunPtr (Ptr a -> IO ()) _mm_malloc :: Storable a => Int -> Int -> IO (ForeignPtr a) _mm_malloc s l = do -- This fails: -- Ambiguous type variable `a0' in the constraint: -- (Storable a0) arising from a use of `sizeOf' -- v <- c_mm_malloc (s * sizeOf (undefined :: a)) l newForeignPtr _mm_free_stub undefined -- This allocates a 16 byte aligned output buffer, takes 2 existing ones and -- calls some FFI function to perform some magic. -- The implementation could run inside ST, if the FFI import (which e.g. works -- on a mutable buffer and returns IO ()) is lifted into ST using unsafeIOToST mySIMDFun :: SIMDVector A16Byte a -> SIMDVector A16Byte a -> SIMDVector A16Byte a mySIMDFun a b = undefined

3 3

cabal equivalent to "make -k"?
by Omari Norman 06 Jul '12

06 Jul '12

When using make (or, at least, GNU make) the "-k" option keeps going as far as possible after a compilation error. It's handy during developing--for instance, "I know half of my code is busted, but I just want to see if this file compiles." Is there a similar way to do this with cabal? Thanks. --Omari

1 0

ANNOUNCE: lens-family 0.0.0
by roconnor＠theorem.ca 06 Jul '12

06 Jul '12

I'm pleased to announce the first release of lens-family-core and lens-family. This package provide first class(†) functional references. In addition to the usual operations of getting, setting and composition, plus integration with the state monad, lens families provide some unique features: * Polymorphic updating * Cast projection functions to read-only lenses * Cast semantic editor combinators to modify-only lenses (†) For optimal first-class support use the lens-family package with rank 2 / rank N polymorphism. Lens.Family.Clone allows for first-class support of lenses for those who require Haskell 98. -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

2 1

Posting jobs on Haskellers.com
by Bartosz Milewski 06 Jul '12

06 Jul '12

There are no job postings on Haskellers.com and I'm wondering whether it's because you have to wait for the "verified" status before you can post (and that's after you have successfully verified your email). Posting the job on the CUFP site, on the other hand, was painless: http://cufp.org/jobs/haskell-systems-administrator .

1 1

Parallel Haskell Digest 11
by Eric Kow 06 Jul '12

06 Jul '12

Parallel Haskell Digest 11 ========================== HTML version: http://www.well-typed.com/blog/67 Hello Haskellers! It's time for another Parallel Haskell Digest! Unfortunately, this may just be our last one, at least within the context of the Parallel GHC project. That said, we may as a community be at the very beginnings of Haskell as *the* language of choice for your parallel and concurrent needs. Maybe we need to keep something like the Digest going to help our little FP monster through its infancy? Any volunteers in the community? If you're interested in picking up the torch, please give us a shout! Otherwise, if you can't take on a (perhaps rotating) digest commitment, but still want to help, would you be kind enough to fill out a small [survey](http://goo.gl/bP2fn) on the digest? There are just five questions on it, plus a feedback form. Anything you can say will help those of us in the Secret Haskell Propaganda Commitee to fine tune our efforts: http://goo.gl/bP2fn It's been a fantastic year for me, working on the Parallel GHC project, learning about all sorts of neat ideas and technologies (as a basic parallel-naive Haskeller), and trying to reflect them back in a way that hopefully helps the broader community. Thanks to all of you in the parallel Haskell world first for cranking out all this great stuff for us to use, and second for your patience and support. Thanks especially to my follow Well-Typed-ers for all the fun chats, the feedback on drafts, and help getting up to speed. One last thing before signing off as your Parallel Haskell Digester. While the digest may be coming to an end, there will at least be one encore! It turns out we had so much to say in our last word of the month, that we'll have to put in in a follow-up posting. In the meantime, we'll just leave you with a little teaser… News ---------------------------------------------------------------------- * [Announce: Haskell Platform 2012.2.0.0][n1] (3 Jun) The new Haskell Platform is out! If you've been waiting for Haskell Platform before moving on GHC 7.4, now's a great time to upgrade. Of particular interest to parallel Haskellers, this latest GHC offers better profiling flags, multicore profiling, vastly improved DPH, event logging [allows ThreadScope spark profiling], and more convenient RTS flags. * [Introducing FP Complete][n2] (6 Jun) You might have Bartosz Milewski around. If not, have a look at the [Downfall of Imperative Programming][downfall]. Bartosz posted a quick message introducing himself to the community along with the new company FP Complete, which aims to commercialise Haskell. Bartosz believes that “now is the right time for Haskell to become a strong software industry player, especially that functional programming is being widely recognized as the answer to the recent multicore and GPU explosion.” We'll hopefully find out more about FP Complete have in mind as their plans stabilise a bit. * [3 year Bioinformatics R&D position in Granada, Spain][n3] Love Functional Programming and concurrency? If you are a CS/Math/IT graduate without a PhD, and have had no more than 4 years of research experience, and have not lived in Spain for more than 12 months (within the last 3 years), Era7 has a position for you! You'll be hacking Scala and using AWS for everything. So if Akka is the sort of thing you're into, this could be the job for you. Word of the month (teaser!) ---------------------------------------------------------------------- The word of the month series has given us a chance to survey the arsenal of Haskell parallelism and concurrency constructs: * some low level foundations (sparks and threads), * three ways to do parallelism (parallel arrays, strategies, dataflow), * and some concurrency abstractions (locks, transactions, channels) The Haskell approach has been to explicitly recognise the vastness of the parallelism/concurrency space, in other words, to provide a multitude of right tools for a multitude of right jobs. Better still, the tools we have are largely interoperable, should we find ourselves with jobs that don't neatly fit into a single category. The Haskell of 2012 may be in a great place for parallelism and concurrency, but don't think this is the end of the story! What we've seen so far is only a snapshot of the technology as it hurtles through the twenty-tens (How quaint are we, Future Haskeller?). While we can't say what exactly the future will bring, we can look at one of the directions that Haskell might branch into in the coming decade. The series so far has focused on things you might do with a single computer, using parallelism to speed up your software, or using concurrency abstractions to preserve your sanity in the face of non-determinism. But now what if you have more than one computer? Our final word of the month is *actor*. Actors are not specific to distributed programming; they are really more of a low level concurrency abstraction on a par with threads. And they certainly aren't new either. The actor model has been around since the early 70s at least, and has been seriously used for distributed programming since the late 80s with Erlang. Can you guess where this word of the month is going? We have a bit more to say about it shortly, so while this is the last Parallel Haskell Digest, watch this space for the final word of the month :-) Parallel GHC project update ---------------------------------------------------------------------- Our work on the [distributed-process][dist-p] implementation of Cloud Haskell continues apace. We're almost there, having implemented most of the API described in the original [Epstein *et al*][ch-pdf] paper, except for node configuration and initialisation. We are very excited to be getting this out of the door soon and into your hands. In fact, we've even submitted a proposal to present this work at the upcoming [Haskell Implementors Workshop][hiw]; so hopefully you'll be able to join Duncan and Edsko in Copenhagen and catch up on the Cloud Haskell news. As for ThreadScope, we last mentioned that we were working to make use of information from hardware performance counters (specifically, Linux Perf Events). This took a bit more work and trickier GHC patches than we had anticipated, but it does seem to be in order now and we are now in the testing phase for the next release. The next ThreadScope release will also include the use of heap statistics from the (eventual) GHC 7.6 RTS, and some user interface enhancements suggested by our users. Tutorials ---------------------------------------------------------------------- * [Parallel and Concurrent Haskell Course slides][t1] Looks like the recent Summer School was a great time for all! We had expert Haskellers talking parallelism and concurrency, a chateau, good food, and lots of wine. Did you miss out? We can't help with the wine, but if you'd like to get in on some of the parallel action, check out Simon's slides. There are seven lectures in all, and some [lab exercises][lab-exo] to go with them: 1. Basic pure parallelism 2. The Par Monad 3. Basic concurrency 4. Software Transactional Memory 5. Concurrent network servers 6. Distributed programming 7. GPU programming with Accelerate * [Threading and Gtk2Hs][t2] “So you're writing a Gtk2Hs application and you need to do some threading.” Daniel Wagner has just the tutorial for you. The post comes in two parts. First Daniel gives it all away with two keys points (and a simple concrete example): 1. Make all Gtk calls from the main thread. If other threads need to affect the interface, use `postGUIAsync` or `postGUISync` to send your code to the main thread. 2. Link your program with the threaded runtime system by passing GHC the `-threaded` option at link time. For readers who want to learn more, Daniel then goes into much more depth: the things that threading hard both in its own right and when working in Gtk2Hs in particular; the perils of using `unsafe` FFI imports (as opposed to `safe` ones); a peek into the Gtk2Hs guts showing its interaction with Gtk and glib; and finally, some of the possible pitfalls, wrong things Daniel believed when he started and what he now believes instead. Blogs and packages ---------------------------------------------------------------------- * [GHC-7.4.2-Eden - Parallel Haskell on multicore and cluster systems][b0] (17 Jun) There is more than one way to do parallelism and distributed programming in Haskell. Mischa Dieterle announced a new release of [Eden][eden], an extension of Haskell which is “tailored for distributed systems but works equally well on multicore architectures”. These extensions consist of a small number of constructs for working with *processes* (processes work within disjoint address spaces and do not share any data). Eden provides automatic process handling to reduce the amount of low-level detail needed to implement parallel algorithms, but also allows for the explicit control you may need to get good performance. You can either install the full Eden system including the compiler (GHC with the Eden parallel runtime system), libraries and tools; or just install a thread simulation by using a standard GHC to install the libraries and tools off Hackage. * [Forklift - a pattern for performing monadic actions in a worker thread][b1] (7 Jun) Apfelmus recently noticed a recurring applied Haskell puzzle: how do you combine two IO-wrapping monads that don't lend themselves to being combined via monad transformers? This arose in the context of Shae Erisson's Summer of Code Project (Web based GHCi) which uses webserver and interpreter packages providing monads of their own. A typical approach would be to run separate threads and have the two communicate using something like an `MVar`; but each time reinvent this solution, we end up creating some mini communication protocol specific to the task. Apfelmus suggests a more generic variant of this approach, which he calls the “forklift pattern” because it consists in *forking* a worker thread to *lift* arbitrary monadic actions into IO. data ForkLift m = ForkLift { requests :: Chan (m ()) } carry :: MonadIO m => ForkLift m -> m a -> IO a The worker thread maintains a queue of requests. To run an arbitrary action of type `m a`, you “carry” it over into `IO` with a helper function that wraps it up in an `MVar` sandwich, sticks it on the queue, and reads the `MVar` to get the result back. See Apfelmus's posting to see this cute trick in action. * [The Flavours of MVar][b2] (4 Jun) Neil Mitchell finds that that the flexibility of the `MVar` can leave some room for confusion: both taking from and putting to an `MVar` one can block, whereas it is likely that you only expect it to block on one of those. In a quick and practical tutorial, Neil whips through three `MVar` patterns that he tends to use regularly: * lock: guaranteed single-threaded access to some resource * var: thread-safe mutable variables that never block on put * barrier: starts empty, is written to once, then read one or more times. Building on these Neil shows a couple of examples of how one might go one to combine these MVar uses to to get higher level abstractions: an action that can be invoked multiple times but runs at most once, and a queue that collects messages individually and delivers them in bulk. Check his post out, and maybe see why `join $ modifyMVar …` is becoming one of his favourite idioms. * [Being more clever about vectorising nested data parallelism][b3] (4 Jun) Manuel Chakravarty tumbles: Our new draft paper [on Vectorisation Avoidance][chak1] introduces a novel program analysis for nested data parallelism that lets us avoid vectorising purely scalar subcomputations. It includes a set of benchmark kernels that suggest that vectorisation avoidance improves runtimes over merely using array stream fusion. * [Repa 3: more control over array representations with indexed types][b4] Another paper from the UNSW parallel Haskellers: We have got a new draft paper on [Guiding Parallel Array Fusion with Indexed Types][chak2]. It describes the design and use of the 3rd generation Repa API, which uses type indices to give the programmer control over the various parallel array representations. The result are clearer programs that the compiler can more easily optimise. The implementation of Repa 3 is ready for use on Hackage in the repa package. * [Protocol Buffers 2.0.7][b8] (19 May) Chris Kuklewicz is back! In the last digest, some folks in the community were looking for him because they had patches for the protocol buffers package family. Chris has not only resurfaced, but released an update to the packages, making them compile with GHC 7.4.1 and handle missing package names better. * [Generics and Protocol Buffers][b6] (20 May) Nathan Howell thinks the protocol-buffers package is great: full-featured, well-tested, no complaints about performance. However, maintaining `.proto` files is “more than just a chore”. The `hprotoc` tool could help but is trickyp to integrated properly into the build system. Maybe there's another way, one which does not involve separate files or build tools. Have a look at his [GitHub Gist][gproto] for a promising alternative solution using the [type-level][type-level] library. * [SafeSemaphore][b9] (2 Jun) Chris Kuklewicz has a problem, a solution, and a plea for help. * Problem: Control.Concurrent.QSem (and QSemN, SampleVar) are [broken][ghc3160] (they provide no exception safety). * Solution: his [SafeSemaphore][safesema] package, just updated to 0.90, with several safer alternatives. * Plea: Would it be possible to replace parts of GHC with SafeSemaphore, so as to unbreak the Haskell Platform? It looks like Chris' plea has been heard, as Simon Marlow has recently suggested importing the STM version for GHC 7.6.1 * [Paraiso][paraiso] (7 Jun) Kazu Yamamoto [announced][b10] a couple of new parallel libraries from Japan. The first is Paraiso (by Takayuki Muranushi of Monadius fame), a high-level language for implementing explicit partial-differential equations solvers on supercomputers as well as today's advanced personal computers. * [GTALib][gtalib] (7 Jun) Also from the Japan Parallel Haskell workld, is GTALib by Kendo Emoto. It provides core functionalities of the GTA programming framework described in the paper [Generate, Test, and Aggregate A Calculation-based Framework for Systematic Parallel Programming with MapReduce][gta] Mailing lists ---------------------------------------------------------------------- * [How to write Source for TChan working with LC.take?][m1] (20 May) Hiromi Ishii is writing a Data.Conduit `Source` that supplies its values from a `TChan`. He has three versions, one using the raw Pipe constructors directly, one using `sourceState`, and one using `yield`. The `yield' version does not seem to work as expected. At first this seemed like an unfortunate necessity, but after putting some thought into it, Michael Snoyman proposed some [modifications to conduit's await/yield][b5] functions, which should allow Hiromi to write things in the intuitive way. * [Parallel cooperative multithreading?][m2] (22 May) Benjamin Ylvisaker was wondering if it'd be possible to implement something like [Observationally Cooperative Multithreading][ocm-pdf] (OCM) in Haskell. The paper discusses Lua, C, and C++ implementations. Ben thinks that Haskell would be an awesome fit such a framework. The premise behind OCM is that cooperative concurrency can be easier than preemptive concurrency, because you can use reason sequentially between invocations of pause/yield/wait. Historically, it has only worked on single processors, because the blocks of code between the p/y/w calls need to be run atomically. Recent research means we know more about how to efficiently run blocks of code atomically, so maybe cooperative concurrency can make a comeback? Ryan Newton thinks the comeback is indeed happening. He points in the Haskell world to monad-par's use of ConT as an example of a a framework in which tasks cooperatively yield control whenever their desired input data is not yet available. Mario Blažević has also thought about cooperative concurrency in Haskell, particularly in context of his monad-coroutine library; however, he found no speedups when he added support for running multiple co-routines in parallel. Ketil Malde is sceptical that the proposed approach would be better than using STM. He wonders if the paper's critique of STM applies to implementations that keep transactional data are segregated by the type system. * [How to translate Repa 2 program to efficient Repa 3 code?][m3] (26 May) Michael Serra posted a StackOverflow thread asking about the [differences between Repa 2 and 3 APIs][s1]. He has some simple image convolution tests with which run fast enough in Repa 2 with judicious use of `force`. But when translating the tests to Repa 3, he can't quite work out how to get the same kind of performance. See the thread on StackOverflow for more details. In short, `computeP` is the new `force`. * [Is Repa suitable for boxed arrays?...][m4] (3 Jun) Stuart Hungerford needs to build a 2D Array of boxed Haskell values. He's attracted to Repa, but couldn't work out from the documentation if it would work with arbitrary values. Moreover, getting the examples to work. Ben Lippmeier replies that it should work (the array type would be something like `Array V DIM2 Float`). The documentation is out of date (it's for Repa 2 and Repa 3 is different). Until somebody gets a chance to update the documentation, try the [Repa 3 paper][repa3-pdf], Ben just submitted for Haskell Symposium 2012. * [Status and roadmap for Cloud Haskell?][m5] (19 May) Ben Lee is very interested in the our work at Well-Typed on `distributed-process`, the followup implementation of Cloud Haskell. How's progress? As mentioned in the Parallel GHC news above, we're almost there! Edsko de Vries says that so far we've been focusing on two aspects of the new implementation, the design of the transport API, and a robust TCP implementation to sit on top of it. These two parts are nearly done. Meanwhile, we've been laying down [some documentation][dp-docs] on our GitHub project wiki. If you want to help out, we'd love if you could play with the TCP transport, and try to write some transports of your own. * [`anyP' in DPH?][m6] (21 May) Rob Stewart is trying to find the `anyP` function for Data Parallel Haskell. Ben Lippmeier says that DPH is in flux at the moment and that the current user facing API can be found in [dph-lifted-vseg][dph-lv] which provides an `orP` function. * [Everybody should write everything in Go?][m7] (28 May) Ryan Hayes posted a small [snippet of Go][go-snippet] showing how friendly he found it for writing concurrent programs, “No pthread... not stupid crap... just works!”. The program seems to create 4 threads which print out 1 to 100 each. What do Haskellers think? See the comments for some discussion between Haskell people like Simon Marlow, and some folks in the Go community about our respective approaches to the problem. * [Proposal: Control.Concurrent.Async][m8] (8 June) Deep into writing his book on Parallel Haskell, Simon Marlow proposes a higher-level concurrency API for the base package. The proposed [Control.Concurrent.Async][cc-async] would help make sure that exceptions in child threads are dealt with (returned or passed up), and that threads aren't accidentally left running in the background. A few Haskellers commented that they would prefer that base be kept minimal as possible, and have counter-proposed making it a package to be included in the Haskell Platform instead. See the thread for some discussion on the API itself. StackOverflow and Reddit ---------------------------------------------------------------------- * [What are the key differences between the Repa 2 and 3 APIs?][s1] * [Does `par` create another thread?][s2] * [How to improve performence of this Haskell code?][s3] * [Haskell: Why was `par` defined the way it was?][s4] * [Method for capturing monad stack state][s5] * [Killing a thread when MVar is garbage collected][s6] * [Improving simulation performance via concurrency][s7] * [Haskell framework to parallelize non-threadsafe C++ lib][s8] * [Thread-safe state with Warp/WAI][s9] * [How to use multiple cores when compiling with GHC? : haskell][r1] Help and Feedback ---------------------------------------------------------------------- Well, this is the end of the Haskell Parallel Digest, but feedback would still be much appreciated! Get in touch with me, Eric Kow, at <parallel(a)well-typed.com>. Bye for now! [ch-pdf]: http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/remot… [dist-p]: https://github.com/haskell-distributed/distributed-process [downfall]: http://fpcomplete.com/the-downfall-of-imperative-programming/ [hiw]: http://www.haskell.org/haskellwiki/HaskellImplementorsWorkshop [lab-exo]: http://community.haskell.org/~simonmar/lab-exercises-cadarache.pdf [eden]: http://www.mathematik.uni-marburg.de/~eden [chak1]: http://www.cse.unsw.edu.au/~chak/papers/KCLLP12.html [chak2]: http://www.cse.unsw.edu.au/~chak/papers/LCKP12.html [paraiso]: http://hackage.haskell.org/package/Paraiso [gtalib]: http://hackage.haskell.org/package/GTALib [gta]: http://research.nii.ac.jp/~hu/pub/esop12.pdf [ghc3160]: http://hackage.haskell.org/trac/ghc/ticket/3160 [safesema]: http://hackage.haskell.org/package/SafeSemaphore/ [gproto]: https://gist.github.com/2757253 [type-level]: http://hackage.haskell.org/package/type-level [dp-docs]: https://github.com/haskell-distributed/distributed-process/wiki [dph-lv]: http://hackage.haskell.org/package/dph-lifted-vseg [cc-async]: http://community.haskell.org/~simonmar/async-stm/Control-Concurrent-Async.h… [repa3-pdf]: http://www.cse.unsw.edu.au/~benl/papers/guiding/guiding-Haskell2012-sub.pdf [ocm-pdf]: http://www.cs.hmc.edu/~stone/papers/ocm-unpublished.pdf [go-snippet]: https://gist.github.com/3010649 [n1]: http://www.haskell.org/pipermail/haskell-cafe/2012-June/101579.html [n2]: http://www.haskell.org/pipermail/haskell-cafe/2012-June/101632.html [n3]: http://functionaljobs.com/jobs/111-3-year-postgraduate-rd-position-at-era7-… [n4]: http://tomschrijvers.blogspot.co.uk/2012/05/ifl-2012-call-for-papers.html [t1]: https://plus.google.com/107890464054636586545/posts/LThYZELANCg [t2]: http://dmwit.com/gtk2hs/ [b0]: http://www.haskell.org/pipermail/haskell-cafe/2012-June/101808.html [b1]: http://apfelmus.nfshost.com/blog/2012/06/07-forklift.html [b2]: http://neilmitchell.blogspot.co.uk/2012/06/flavours-of-mvar_04.html [b3]: http://tumblr.justtesting.org/post/24399176080/being-more-clever-about-vect… [b4]: http://tumblr.justtesting.org/post/24398752358/repa-3-more-control-over-arr… [b5]: http://www.yesodweb.com/blog/2012/05/next-conduit-changes [b6]: http://breaks.for.alienz.org/blog/2012/05/20/generics-and-protocol-buffers/ [b8]: http://www.haskell.org/pipermail/haskell-cafe/2012-May/101313.html [b9]: http://www.haskell.org/pipermail/haskell-cafe/2012-June/101567.html [b10]: http://www.haskell.org/pipermail/haskell-cafe/2012-June/101649.html [b12]: http://fpcomplete.com/asynchronous-api-in-c-and-the-continuation-monad/ [m1]: http://www.haskell.org/pipermail/haskell-cafe/2012-May/101318.html [m2]: http://www.haskell.org/pipermail/haskell-cafe/2012-May/101359.html [m3]: http://www.haskell.org/pipermail/haskell-cafe/2012-May/101454.html [m4]: http://www.haskell.org/pipermail/haskell-cafe/2012-June/101573.html [m5]: https://groups.google.com/d/msg/parallel-haskell/A6mXn1Wv-KY/-63SHoGU31wJ [m6]: https://groups.google.com/d/msg/parallel-haskell/Ykm3QJT12yw/8HpnoP8qsugJ [m7]: https://plus.google.com/app/plus/mp/588/#~loop:view=activity&aid=z13pwzbajp… [m8]: http://www.haskell.org/pipermail/libraries/2012-June/017892.html [s1]: http://stackoverflow.com/questions/10747079/what-are-the-key-differences-be… [s2]: http://stackoverflow.com/questions/10724946/does-par-create-another-thread [s3]: http://stackoverflow.com/questions/10557055/how-to-improve-performence-of-t… [s4]: http://stackoverflow.com/questions/10166640/haskell-why-was-par-defined-the… [s5]: http://stackoverflow.com/questions/11073610/method-for-capturing-monad-stac… [s6]: http://stackoverflow.com/questions/10871303/killing-a-thread-when-mvar-is-g… [s7]: http://stackoverflow.com/questions/10627980/improving-simulation-performanc… [s8]: http://stackoverflow.com/questions/10567223/haskell-framework-to-paralleliz… [s9]: http://stackoverflow.com/questions/10449819/thread-safe-state-with-warp-wai [r1]: http://www.reddit.com/r/haskell/comments/uyy80/how_to_use_multiple_cores_wh… -- Eric Kow <http://erickow.com>

2 3

OpenShift a free PaaS from RedHat
by C K Kashyap 06 Jul '12

06 Jul '12

Hi Folks, I just found out about OpenShift - its a free PaaS from RedHat. It has some interesting offerings. It does not support Haskell out of the box as of now. Please do check it out and if you like it - vote for Haskell support on it here - https://openshift.redhat.com/community/content/support-for-haskell Meanwhile, I am trying to get complied Haskell executable to run on that platform. Regards, Kashyap

4 6

HUnit/cabal integration
by Richard Cobbe 06 Jul '12

06 Jul '12

I'm working on a little library package (purely for my own consumption) that's built with Cabal, and I have a couple of questions about the pragmatics of using HUnit for it. First, I'd like to be able to run my tests via "cabal test" from the shell prompt. I've seen <http://hackage.haskell.org/trac/hackage/wiki/UpgradingTests> and followed that, and it basically works. I'm curious if I'm doing it in the best (or at least most idiomatic) way. I've included my cabal file and test driver below, for specifics. Two questions: First: the web page I cite above describes the interface that the test binary must support to work with cabal, specifically w.r.t. the binary's exit code. "Your test suites likely already fit this model. However, if you are using an old version of QuickCheck or HUnit, your executable may not be returning the correct error code." This seems to me to suggest that recent versions of HUnit automatically take care of generating the exit code, but I've found that I have to examine HUnit's results and synthesize the exit code manually, as in the driver program below. (I'm running HUnit 1.2.4.2, but the interface for 1.2.4.3 doesn't appear to differ on this point.) Am I misinterpreting the wiki page, or am I missing something in HUnit's API that generates the exit code automatically? Second: Am I specifying the Build-Depends correctly for the Test-Suite? Specifically: do I need to state a dependency on the library defined in the same package, or does it pick that up automatically? Further, foo-tests doesn't use parsec directly. Is the transitive dependency automatically provided for me, or do I need to list it explicitly as below? Thanks much, Richard My cabal file: Name: foo Version: 0.0 Cabal-Version: >= 1.2 Author: Richard Cobbe Synopsis: Sample cabal package for HUnit integration Build-Type: Simple Library Exposed-Modules: Foo, Foo.Parser, Foo.Show Build-Depends: base >= 4.3.1.0 && < 5, parsec >= 3.1.2 Test-Suite foo-tests main-is: foo-tests.hs type: exitcode-stdio-1.0 Build-Depends: base >= 4.3.1.0 && < 5, parsec >= 3.1.2, HUnit >= 1.2.4.2 and foo-tests.hs: module Main where import Test.HUnit import qualified Foo.Parser import System.Exit main :: IO () main = do c <- runTestTT ("Foo" ~: Foo.Parser.tests) if (errors c == 0 && failures c == 0) then exitWith ExitSuccess else exitWith (ExitFailure (-1))

2 2