News aggregator

TopSort

Haskell on Reddit - Wed, 12/10/2014 - 10:19am
Categories: Incoming News

Imagine... (x-post from /r/functionalprogramming)

Haskell on Reddit - Wed, 12/10/2014 - 10:03am
Imagine no iteration, It's easy if you try, No state below us, Above us only Y, Imagine all the people, Coding with lambdas... Imagine no mutation It isn't hard to do Nothing to deadlock And no pointers too Imagine all the people Coding in Haskell... You may say I'm no hacker But I'm not the only one I hope someday you'll join us And compsci will be as one Imagine no frustration I wonder if you can No need for state or pointers A world of monads Imagine all the people Programming in peace... You may say I'm no hacker But I'm not the only one I hope someday you'll join us And compsci will be as one submitted by Closures
[link] [1 comment]
Categories: Incoming News

Type systems and logic

del.icio.us/haskell - Wed, 12/10/2014 - 12:05am
Categories: Offsite Blogs

Type systems and logic

del.icio.us/haskell - Wed, 12/10/2014 - 12:05am
Categories: Offsite Blogs

Philip Wadler: How to save US

Planet Haskell - Tue, 12/09/2014 - 11:09pm
A short, inventively presented, video from Lawrence Lessig, making the case that before we can solve all the other problems in the US, the first problem we must solve is to take big money out of politics, and how we can do it via Mayday.
Categories: Offsite Blogs

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

www.cs.ox.ac.uk

del.icio.us/haskell - Tue, 12/09/2014 - 9:15pm
Categories: Offsite Blogs

www.cs.ox.ac.uk

del.icio.us/haskell - 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

Perfect!

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

Jan Stolarek: Why dependent types matter (in Haskell)

Planet Haskell - Tue, 12/09/2014 - 8:53am

A year ago I published Agda code for “Why dependent types matter” paper by Thorsten Altenkirch, Conor McBride and James McKinna. Now I rewrote that code in Haskell. This work is similar to my recent conversion of weight-biased leftist heaps from Agda to Haskell so I won’t go into technical details. As usual you can view the code on Github.

Categories: Offsite Blogs

Erik Meijer : [a] vs Maybe a

Haskell on Reddit - Tue, 12/09/2014 - 4:46am

In fp101x Erik Meijer is adamant that a singleton list is a better option than Maybe to represent possibly invalid return values.

I can see his point, but worry about the possibility of multiple returns, so it becomes just the same problem in a different guise.

What do others think of this?

submitted by alan_zimm
[link] [43 comments]
Categories: Incoming News