News aggregator

Philip Wadler: SNAPL update

Planet Haskell - Tue, 12/09/2014 - 10:39pm
SNAPL, taking place 3-6 May in Asilomar, now has a publisher. Proceedings will appear in the LIPIcs series published by Dagstuhl. Five pages in ACM style is about eight pages in LIPIcs style, so the SNAPL call for papers has changed the paper length accordingly.

Previously: SNAPL.
Categories: Offsite Blogs

Libraries for using regexes on Text

Haskell on Reddit - Tue, 12/09/2014 - 10:29pm

Are there any libraries for using regexes with the Text type that have a friendlier API than text-icu? And for String, which is the preferred regex library?

submitted by seriousreddit
[link] [15 comments]
Categories: Incoming News - Tue, 12/09/2014 - 9:15pm
Categories: Offsite Blogs - Tue, 12/09/2014 - 9:15pm
Categories: Offsite Blogs

Oliver Charles: 24 Days of GHC Extensions: Nullary Type Classes

Planet Haskell - Tue, 12/09/2014 - 6:00pm

While I wait for a few more guest posts to soldify, I thought it might be fun to look at another new extension to GHC - NullaryTypeClasses.

> {-# LANGUAGE NullaryTypeClasses #-}

Ordinarily in Haskell, a type class is defined as the following:

class ctx => C a where ...

That is, our type class can have a context, and can operate on a single type parameter. However, working with one type is a restriction - later, we’ll see about working with multiple type parameters is there any reason we couldn’t work on no type parameters?

It sounds crazy, but GHC can do just that! The linked documentation has one scenario of when you may want to do that - if you need to make a controversial assumption, by using a nullary type class you can give your end users the choice as to whether or not they want to commit to using code that requires that assumption to hold.

However, nullary type classes can also be used as a form of implicit configuration. For example, let’s assume we’re building a Haskell library, and we’d like to give our users the ability to log its activity. There are many ways to log messages these days - in development we might use STDERR, but in production we might push our logs directly to journald or syslog.

By using nullary type classes, we can abstract over this logging function, and let the end user provide a logging strategy. To begin, we define our type class, mostly as normal - but we don’t use any type parameters:

> class Logger where > logMessage :: String -> IO ()

The presence of this type class allows us to call logMessage, but defer the implementation to the user of the library:

> type Present = String > queueNewChristmasPresents :: Logger => [Present] -> IO () > queueNewChristmasPresents presents = do > mapM (logMessage . ("Queueing present for delivery: " ++)) presents > return ()

Notice how our library function clearly indicates the assumption - here we are assuming that it will be possible to log a message, using IO.

Now to provide a logging implementation, all we have to do is provide the instance for the Logger type class:

> instance Logger where > logMessage t = putStrLn ("[XMAS LOG]: " ++ t)

Running our library function does just what we would expect:

.> queueNewChristmasPresents ["Cuddly Lambda", "Gamma Christmas Pudding"] [XMAS LOG]: Queueing present for delivery: Cuddly Lambda [XMAS LOG]: Queueing present for delivery: Gamma Christmas Pudding


If you’re feeling a little uncomfortable now - I’m with you. It’s not clear to me whether this is really a good idea or not, but it’s nice that it is available in GHC. In a future post we’ll look at another extension that attempts to solve the implicit configuration problem.

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

Categories: Offsite Blogs

Teach, Don't Tell

Haskell on Reddit - Tue, 12/09/2014 - 2:10pm
Categories: Incoming News

There is a documentation problem, stop pretending there isn't. An extraction of a twitter thread.

Haskell on Reddit - Tue, 12/09/2014 - 12:11pm

I tweeted about the documentation problems, here is the thread that followed:

Exactly. Library usage requires that the burden of proof be on the producer, not the consumer. A good general rule of thumb.

one of my main gripes with haskell libs I’d like to use

Don't know how the first two got so bad. There's no technical reason why it should be that way...

(the first two parts of my tweet were about documentation and giving people examples of how to use your library)

haskell programmers are lazy ;)

But disproportionately lazy it seems.

but I agree in the large, it's frustrating when you want to use something someone else has done and it takes hours.

I wasted so much time reverse engineering so many basic libraries, I'm become more disillusioned with Haskell some days.

Yep, I totally hear you. I love Haskell but if it's going to move forward, documentation needs to become a priority.

I don't know anymore, all seems pretty pointless.

Stop pretending there isn't a problem, you'll make it worse by asserting otherwise. We need to stop making excuses, other people using worse tools are doing a better job.

We can do better.

Not everybody is good at writing libraries. Not everybody is good at writing documentation. Should we consider a "match-making" process for finding (perhaps newbies?) people willing to dig in and learn a library with "fresh eyes" sufficiently to write good documentation and examples? It wouldn't require that much expertise in most cases.

I don't want to wait that long for doing something now, but a GSoC project could made for a "community documentation sweep".

submitted by Mob_Of_One
[link] [87 comments]
Categories: Incoming News

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