News aggregator

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

Christopher Done: Proposal: bind

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

I often find myself writing:

fmap (mu bar) (foo zot)

Then I decide to change the type of mu, so instead I want to just write:

bind (mu bar) (foo zot)

Which is just like fmap but the function can run in the monad. Similar to traverse:

(Traversable t, Applicative f) => (a -> f b) -> t a -> f (t b)

As someone who isn’t a fan of operators, I generally am appreciative of alternative regular plain English word versions of functions, which I find easier to type, read and edit. Currently without defining such a handy name, I have to transform the code to this:

mu bar =<< foo zot

The name for this function is a no-brainer ((>>=) is now pronnounced “bind”):

bind :: Monad m => (a -> m b) -> m a -> m b bind = (=<<)

For comparison, the not-very-pleasant <$> and <*> each have word alternatives, fmap and ap.

I submitted this to the haskell libraries mailing list, but include it here for future reference.

Categories: Offsite Blogs

Oliver Charles: 24 Days of GHC Extensions: Recursive Do

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

Ordinarily, when we’re programming computations under a monad, we’re limited to forming bindings in the order they appear in a do block. However, there are a class of monads that support extra value recursion through the type class MonadFix. This extra functionality has special syntax support in GHC, and can be useful in a variety of situations.

MonadFix and Recursive Bindings

First of all, we’ll take a look at how MonadFix can be used to easily create recursive data structures. Before we get to that, lets look at a little program that works with rose trees. We’ll begin with the definition of a rose tree:

> {-# LANGUAGE RecursiveDo #-} > import Control.Monad.Fix > data RoseTree a = RoseTree a [RoseTree a] > deriving (Show)

A rose tree is a node paired up with a list of child trees. Thus this data structure is a simple model of a multi-way tree. One thing we’d like to be able to do with our rose trees is to pair each element in the tree with the largest element in the entire tree. For example, if we have the following:

> exampleTree :: RoseTree Int > exampleTree = RoseTree 5 [RoseTree 4 [], RoseTree 6 []]

then we can pair each item in the tree with the biggest element - 6:

.> pureMax exampleTree RoseTree (5, 6) [RoseTree (4, 6) [], RoseTree (4, 6) []]

On the surface, we might think that this operation should take two traversals of the tree - one to find out what the largest element is, and then another pass through the tree to change all the elements. Interestingly, this can actually be done in a single pass, if we exploit laziness! Here’s how:

> pureMax :: Ord a => RoseTree a -> RoseTree (a, a) > pureMax tree = > let (t, largest) = go largest tree > in t > where > go :: Ord a => a -> RoseTree a -> (RoseTree (a, a), a) > go biggest (RoseTree x []) = (RoseTree (x, biggest) [], x) > go biggest (RoseTree x xs) = > let sub = map (go biggest) xs > (xs', largests) = unzip sub > in (RoseTree (x, biggest) xs', max x (maximum largests))

If you’ve not seen this before - this may seem a little cryptic! Let’s take it slowly. We walk through our tree with the go function. go takes two paremeters - one is the tree that we’re working on, while the other is the known largest element. But wait… don’t we need to calculate the largest element? You’re right - and that’s exactly what we do in go.

Notice that go returns two values - the relabelled rose tree, along with the known largest element in that tree. The magic happens right at the start of pureMax - notice that we pattern match to bind the variable largest, though we also feed in largest to relabel the trees.

What’s happening is that we’re exploiting lazy evaluation - what we actually do is relabel the tree with a thunk at every node. Once we’ve finished recursing the entire tree, we’ve got enough information, should we need to force that node. This technique is known as circular programming, and Richard Bird has a lovely write up on a similar problem - the repmin problem.

So far, we’ve seen a pure solution to the problem, but what happens if we need to use effectful computations to determine the largest value? For example, let’s work with an exclusive secret santa. In this exclusive secret santa, people can invite others into the game - forming a tree of invites. Furthermore, we also have a database lookup function that will tell us what their budget is. We’d like to be able to relabel the invite tree with the minimum budget for fairness. If we had a tree of budgets, that would be easy - we could just use a variation of pureMax above. However, determining the budget requires a database lookup.

It looks like we’re stuck, but what we can do is make an effectful variation of pureMax:

> impureMin :: (MonadFix m, Ord b) => (a -> m b) -> RoseTree a -> m (RoseTree (a, b)) > impureMin f tree = do > rec (t, largest) <- go largest tree > return t > where > go smallest (RoseTree x []) = do > b <- f x > return (RoseTree (x, smallest) [], b) > > go smallest (RoseTree x xs) = do > sub <- mapM (go smallest) xs > b <- f x > let (xs', bs) = unzip sub > return (RoseTree (x, smallest) xs', min b (minimum bs))

If you compare this to pureMax you should notice that the programs are very similar. Infact, all we’ve had to do is replace the pure let x = y bindings with effectful x <- y bindings, and call out to our effectful function. Finally, the magic sauce at the top is to use a new piece of syntax rec. rec comes from the RecursiveDo extension, and while the details are beyond the scope of this post (there’s a whole thesis on it!), we can see here that it serves the same purpose as forming recursive bindings, as we did with let.

To wrap up this example, let’s work with some test data and see how it all plays out:

> budget :: String -> IO Int > budget "Ada" = return 10 -- A struggling startup programmer > budget "Curry" = return 50 -- A big-earner in finance > budget "Dijkstra" = return 20 -- Teaching is the real reward > budget "Howard" = return 5 -- An frugile undergraduate! > inviteTree = RoseTree "Ada" [ RoseTree "Dijkstra" [] > , RoseTree "Curry" [ RoseTree "Howard" []] > ]

Now we can ask our system what budget we should use

.> impureMin budget inviteTree RoseTree ("Ada",5) [RoseTree ("Dijkstra",5) [],RoseTree ("Curry",5) [RoseTree ("Howard",5) []]]

Alright, 5 gold coins it is!

In this post I’ve shown just one of many things that can be done with RecursiveDo syntax. Another common usage of this extension is in reactive-banana - here it’s possible for reactive behaviors to depend on events, where the events sample the same behavior. A more extreme example (if you really want a headache!) is the Tardis monad - a monad where data can travel forwards and backwards in time!


This post is part of 24 Days of GHC Extensions - for more posts like this, check out the calendar.

Categories: Offsite Blogs

Alp Mestanogullari: Rethinking webservice and APIs in Haskell: servant 0.2

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

Earlier this year, I announced the first version of servant. The goal was to speed up webservice development by getting rid of as much boilerplate as possible. It definitely was an improvement but not quite enough. Assisted this time with Sönke Hahn (of Nikki and the Robots fame) and Julian Arni, two of my now ex-coworkers, we completely rewrote everything and came up with a new way to describe webservices APIs in Haskell. This post introduces servant 0.2, which now lives in its own github org.

<section class="level1" id="webservice-apis-as-types"> Webservice APIs as types

The meat of the new servant is the fact that we now describe webservice APIs as types. And we write these types by combining “API combinators”, that each have a precise meaning. We use type-level string literals for static fragments of an endpoint.

Let’s build a webservice to manage an imaginary userbase.

data User = User { firstName :: !Text , lastName :: !Text } deriving (Eq, Show, Generic) instance ToJSON User instance FromJSON User -- corresponds to: GET /users -- returning a JSON-encoded list of User's. type UserAPI = "users" :> Get [User] userAPI :: Proxy UserAPI userAPI = Proxy server :: Server UserAPI server = listUsers where listUsers = return $ Data.Map.elems users users :: Data.Map.Map Int64 User users = Data.Map.fromList [ (0, User "john" "doe") , (1, User "jane" "doe") ] -- spin up a warp server that serves our API main :: IO () main = run 8080 (serve userAPI server)

Endpoints are separated from one another with :<|>, similar to Alternative’s <|> separating alternative parsers. URL Captures, GET parameters, request bodies and headers are strongly typed and only made available to server handlers by explicit mentions in the type for the corresponding endpoint. They automatically become arguments to the handler functions.

Here’s our previous example expanded to make use of these few features.

data User = User { firstName :: !Text , lastName :: !Text } deriving (Eq, Show, Generic) instance ToJSON User instance FromJSON User -- list all users: GET /users type UserAPI = "users" :> Get [User] -- view a particular user: GET /users/:userid :<|> "users" :> Capture "userid" Int64 :> Get User -- search for users: GET /users/search?q=<some text> :<|> "users" :> "search" :> QueryParam "q" Text :> Get [User] userAPI :: Proxy UserAPI userAPI = Proxy server :: Server UserAPI server = listUsers :<|> viewUserById :<|> searchUser where listUsers = return $ Data.Map.elems users -- the captured userid gets automatically passed to this function viewUserById userid = maybe (left (404, "user not found")) return $ Data.Map.lookup userid users -- the 'q' GET parameter's value automatically passed to this function, -- if present. searchUser Nothing = return [] -- no ?q=something specified searchUser (Just q) = return . Data.Map.elems . Data.Map.filter (userLike q) $ users userLike q usr = q `isInfixOf` firstName usr || q `isInfixOf` lastName usr users :: Data.Map.Map Int64 User users = Data.Map.fromList [ (0, User "john" "doe") , (1, User "jane" "doe") ] -- spin up a warp server that serves our API main :: IO () main = run 8080 (serve userAPI server)

This combinator-based approach lets us define server-side behavior and data-dependency with types, letting the library handle all the GET parameter/capture/request body extraction and letting you worry only about what you need to do with these values. But that doesn’t stop there. servant can also generate Haskell and Javascript functions to query servant webservices and API docs.

</section> <section class="level1" id="want-to-read-more-about-this"> Want to read more about this?
  • We have a Getting Started slideshow that walks you through the basics of the library.
  • We have haddocks for the 4 packages that are full of examples and explanations.
    • servant, API types and serving
    • servant-client, for generating haskell functions to query APIs automatically
    • servant-jquery, for generating javascript functions to query APIs automatically
    • servant-docs, for assistance in API docs generation
</section> Posted on December 9, 2014
Categories: Offsite Blogs

Type systems and logic

Haskell on Reddit - Mon, 12/08/2014 - 4:38pm
Categories: Incoming News

Should I use pwstore-fast?

Haskell on Reddit - Mon, 12/08/2014 - 3:16pm


I'm relatively new to Haskell. I convinced my employers that we should use it for an M2M we're building internally. I've been happily hacking away for a couple months and enjoying every second.

Today I came to a question that I know I cannot get wrong: how should I hash my passwords?

I've used the SHA library for computing shasums on file transfers so I started there, but I'd like the library to also take care of some of the other cruft of password management.

pwstore-fast seems to do just that. The interface looks very simple and appealing, but I still don't know how to vet a Haskell library. I checked out the Github page and saw it had been a while since the last commit, but that doesn't necessarily tell me anything about the quality.

So I guess I have three questions: * Is there a standard library everyone is using for password hashing? * Is pwstore-fast a trusted and effective one? * Does anyone have tips for vetting libraries short of reading the source code and assuming I'll know if it's right?


Edit: Looking a little closer in Github, it appears that the project is more active than it first seemed. There was a PR as recent as October 3. I had only looked at the releases page, but the last release there is 2.3 whereas the most recent on Hackage is 2.4.4

submitted by hans2504
[link] [12 comments]
Categories: Incoming News

FP Complete: Dropping GHC 7.4 support in FP Haskell Center

Planet Haskell - Mon, 12/08/2014 - 12:00pm

When we released FP Haskell Center 3.1, we deprecated our support for GHC 7.4. Till now, we've left that support in place to give users a grace window for upgrading to GHC 7.8. I'm announcing our plans to fully remove GHC 7.4 support in a near release, most likely FP Haskell Center 3.3.

One of the main reasons we are removing support is that the library versions compatible with GHC 7.4 are no longer being maintained.

If you are still actively using GHC 7.4 on FP Haskell Center, and would like us to consider extending its lifetime, please let us know (via the feedback link at the top of this page) in the next few weeks.

Categories: Offsite Blogs

Language is not important

Haskell on Reddit - Mon, 12/08/2014 - 10:36am
Categories: Incoming News

The GHC Team: GHC Weekly News - 2014/12/08

Planet Haskell - Mon, 12/08/2014 - 9:33am

Hi *,

Once more, it's time for some news about GHC! This week's regularly scheduled programming (get it?) has brought you...

Closed tickets this week include: #9850, #9005, #9828, #9833, #9582, #8935, #9186, #9480, #9497, #7908, #4347, #3977, #3859, #3844, #3814, #3771, #3739, #2182, #9812, #4921, #7947, #9240, #5401, #3625, #3517, #9444, #9142, #3447, #8894, #3065, #3191, #2697, #2836, #5443, #7736, #2489, #2456, #2204, #9777, #9859, #9869, #9808

Categories: Offsite Blogs

Douglas M. Auclair (geophf): 10 programming challenge sites

Planet Haskell - Mon, 12/08/2014 - 3:30am
Okay. Whoa!

I saw this off the twitter feed: Ten programming challenge sites

And, from it, I have a new love affair:, a problem-solving site for bioinformatics. I love it. What's not to love!
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