8

I am trying to develop a chat server using Haskell.

There are a lot of useful tools like TChan, TSkiplist, forkIO ...etc, but it turns out that most of my code is written inside the IO monads and unsafePerformIO, which sounds very inefficient.

Is it ok to do this, or is haskell not the right tool for this purpose?

AndrewC
  • 32,300
  • 7
  • 79
  • 115
user1748906
  • 526
  • 4
  • 13
  • 1
    Have a look at [Hulk](http://chrisdone.com/posts/2011-01-30-hulk-haskell-irc-server.html) - a start a writing an IRC server in Haskell. – ErikR Oct 16 '12 at 05:21

3 Answers3

19

As a general rule, try to first write code as just pure functions without worrying where the data comes from - just assume it's there.

Next wrap that pure functionality in IO to feed your pure functions data and put the results somewhere. It's OK that there's a lot of this going on in a chat application! The IO monad isn't inefficient at all, it's just that we prefer to keep as much code as we can out of it since that's good design - keep the data crunching apart from the IO. A chat application doesn't do a lot of calculation with the data it gets, so it's OK to have loads of IO code.

I think it's definitely better to stick in the IO monad than use unsafePerformIO, because unsafePerformIO is kind of presenting its result as pure data. I might be tempted to use it to get constants from a configuation file, but I've never actually done so, and there's no point if you're heavily in the IO monad anyway. There's a reason it's called unsafe! Petr Pudlák has good advice in the comment below.

I've heard Haskell's monads described as the best imperative programming language in the world. I could split hairs over that description, but I agree with the sentiment, and yes, stick with Haskell. Haskell is good at at the programming you're using it for.

Community
  • 1
  • 1
AndrewC
  • 32,300
  • 7
  • 79
  • 115
  • 4
    Good answer. Just I'd advocate much more strongly against using `unsafe*`. Using `unsafe*` will make you lose what Haskell enforces you - to separate pure and impure computations. And combined with lazy evaluation, `unsafe*` will make your life miserable. – Petr Oct 16 '12 at 08:42
  • 1
    Good point. I've beefed up the advice against unsafe, but I've left the point about lazy+unsafe for your good comment. – AndrewC Oct 16 '12 at 08:53
  • 3
    It isn't really the *IO* monad in *particular* that is being referred to; Haskell is said to be the "best imperative programming language" because you get to decide *which* imperative language it is: the language with IO, the language with non-determinism, the language with state, a combination of these things, etc. This is sometimes referred to as the "programmable semicolon". – Dan Burton Oct 16 '12 at 14:48
  • 1
    @Dan You make a good contemporary point, but in the original paper, [Tackling the Awkward Squad](http://research.microsoft.com/en-us/um/people/simonpj/papers/marktoberdorf/mark.pdf), Simon Peyton Jones concludes his introduction with "In short, Haskell is the world’s finest imperative programming language." after previously saying "Indeed, the IO monad is the unifying theme of these notes", and it really is only about the IO monad; SPJ _was_ referring to the IO monad in particular, but I agree there is a broader goodness. Applicative Functors are my _favourite_ construct in imperative code. – AndrewC Oct 16 '12 at 22:02
12

Whenever you notice that you have a long function that resides inside the IO monad, it pays off to pause and take a look at the computations that take place. In my experience, it's (almost) always the case that some non-IO related stuff is going on that doesn't need access to input output and can be encapsulated in pure functions.

This has the big advantage that it forces you to find proper abstractions and separate (pure) algorithms from input/output handling. Moreover, it's much easier to verify and test pure functions. Of course, you will still call these pure functions from within some IO a function (e.g. main) but that's perfectly fine.

Peter
  • 1,693
  • 13
  • 18
5

most of my code is written inside the IO monads

That's fine.

and unsafePerformIO

That's bad! Avoid using unsafePerformIO like the plague; it should only be used by veteran Haskellers in very specific circumstances.

Is it ok to do this, or is haskell not the right tool for this purpose?

It's OK to write code in the IO monad, but not OK to use unsafePerformIO. Instead, learn how to compose IO actions using the Monad interface (do notation). Learn which function type signatures need to include the IO type.

Dan Burton
  • 53,238
  • 27
  • 117
  • 198