News aggregator

chrisdone/emacs-haskell-config - Tue, 12/09/2014 - 12:39am
Categories: Offsite Blogs

chrisdone/emacs-haskell-config - Tue, 12/09/2014 - 12:39am
Categories: Offsite Blogs

How often do you find yourself using Either for something besides error handling?

Haskell on Reddit - Mon, 12/08/2014 - 10:55pm

I just realized today I've never seen it used for anything else.

submitted by Hrothen
[link] [38 comments]
Categories: Incoming News

Literate Haskell example?

Haskell on Reddit - Mon, 12/08/2014 - 10:39pm

I've been asking various forums the last few days and received no helpful information, mainly in the form of "You're doing that wrong" or "Don't do that", and I am hoping you can help. I am looking for an example of how to write literate Haskell in such a way as to be accepted by doctest and Haddock, for example. The >>> in my literate scripts seem to keep causing errors messages. Any examples of how to write such a literate script would be greatly appreciated.

submitted by throwaway1234u89
[link] [3 comments]
Categories: Incoming News

Primitive Lenses Question

Haskell on Reddit - Mon, 12/08/2014 - 8:43pm

I'm trying to fiddle around with lenses, prisms and traversals for Elm. However, Elm doesn't support type classes or higher-kinded polymorphism (so I can't take the scrap your type classes approach).

I end up with lenses and prisms like:

module Lens where data Lens s t a b = Lens { view :: s -> a , set :: b -> s -> t } data Prism s t a b = Prism { pure' :: b -> t , matching :: s -> Either t a }

#haskell-lens said that the proper type of a Traversal is

data Traversal s t a b = Traversal { viewT :: s -> [a] , setT :: [b] -> s -> t }

I'm confused by this signature. First, it doesn't seem to match the lens package which allows

set traverse 1 [1, 2, 3]

Second, how do you turn a lens or prism into a traversal with this type?

data Monoid' a = Monoid' { mempty :: a , mappend :: a -> a -> a } fold :: Monoid' a -> [a] -> a fold (Monoid' mempty mappend)= foldr mappend mempty pToT :: Monoid' b -> Prism s t a b -> Traversal s t a b pToT mn pr = Traversal (either (const []) pure . matching pr) (\bs -> either id (const . pure' pr $ fold mn bs) . matching pr) lToT :: Monoid' b -> Lens s t a b -> Traversal s t a b lToT mn ln = Traversal (pure . view ln) (set ln . fold mn)

I'm far from certain that's the right implementation.

submitted by pseudonom-
[link] [5 comments]
Categories: Incoming News

Edward Z. Yang: Unintended consequences: Bound threads and unsafe FFI calls

Planet Haskell - Mon, 12/08/2014 - 6:09pm

A while ago, I wrote a post describing how unsafe FFI calls could block your entire system, and gave the following example of this behavior:

/* cbit.c */ #include <stdio.h> int bottom(int a) { while (1) {printf("%d\n", a);sleep(1);} return a; } /* cbit.h */ int bottom(int a); /* UnsafeFFITest.hs */ {-# LANGUAGE ForeignFunctionInterface #-} import Foreign.C import Control.Concurrent main = do forkIO $ do safeBottom 1 return () yield print "Pass (expected)" forkIO $ do unsafeBottom 2 return () yield print "Pass (not expected)" foreign import ccall "cbit.h bottom" safeBottom :: CInt -> IO CInt foreign import ccall unsafe "cbit.h bottom" unsafeBottom :: CInt -> IO CInt

In the post, I explained that the reason this occurs is that unsafe FFI calls are not preemptible, so when unsafeBottom loops forever, the Haskell thread can't proceed.

This explanation would make perfect sense except for one problem: the code also hangs even when you run with the multi-threaded runtime system, with multiple operating system threads. David Barbour wrote in wondering if my claim that unsafe calls blocked the entire system was out of date. But the code example definitely does hang on versions of GHC as recent as 7.8.3. Based on the title of this post, can you guess the reason? If you think you know, what do these variants of the program do?

  1. Change main = to main = runInUnboundThread
  2. Change the second forkIO to forkOn 2
  3. Add a yield before unsafeBottom, and another yield before print "Pass (not expected)"

The reason why the code blocks, or, more specifically, why the main thread blocks, is because the unsafe FFI call is unpreemptibly running on the operating system thread which the main thread is bound to. Recall, by default, the main thread runs in a bound operating system thread. This means that there is a specific operating system thread which must be used to run code in main. If that thread is blocked by an FFI call, the main thread cannot run, even if there are other worker threads available.

We can thus explain the variants:

  1. main is run in an unbound thread, no blocking occurs, and thus the second print runs.
  2. By default, a forked thread is run on the same capability as the thread that spawned it (this is good, because it means no synchronization is necessary) so forcing the bad FFI call to run on a different worker prevents it from blocking main.
  3. Alternately, if a thread yields, it might get rescheduled on a different worker thread, which also prevents main from getting blocked.

So, perhaps the real moral of the story is this: be careful about unsafe FFI calls if you have bound threads. And note: every Haskell program has a bound thread: main!

Categories: Offsite Blogs

New gtk2hs 0.12.4 release

gtk2hs - Wed, 11/21/2012 - 12:56pm

Thanks to John Lato and Duncan Coutts for the latest bugfix release! The latest packages should be buildable on GHC 7.6, and the cairo package should behave a bit nicer in ghci on Windows. Thanks to all!


Categories: Incoming News