[dllthomas]

On the contrary, the whole point of software is its effects. They are only side effects if you're not able to encode the effects in the type of the function. Haskell doesn't treat effects as less important, it treats them as more important by allowing (and, as a consequence, forcing) you to reason about them explicitly in compiler-checked ways. This lets you do great things like have STM transactions with a guarantee that retrying them won't screw anything up. It also lets you define your own kinds of effects that you want to track and plumb them through your system in a coherent way. And it lets you write code that doesn't care what kind of effects it's working with, and yet which can still be used in contexts like STM that need to apply restrictions.

[marcosdumay]

What I'm not liking about this line of reasoning is that in practice Haskell seems to not go far enough[1].

Yes, you have to declare your effects. In practice that means that most of your code returns IO, and isn't constrained anymore. I don't know if this is a library feature, or an essential feature of the language[2], but it would be very interesting for example to put a GUI together by computing events in functions that returned an "Event" monad, widgets in functions that returned a "GUI" monad, database access in functions in a "DB" monad, etc. Instead, all of those operate on IO.

[1] A completely subjective assessment. [2] I've though for a short while on how to code that, but didn't got any idea I liked.

[tikhonj]

It's not clear that that's the distinction that makes the most sense. I think typing based on capability makes more sense than typing based on purpose. So you would have a type like FSRead and FSWrite which could only read and write from the filesystem, for example. (Ideally with a nice way to combine the two!)

Of course, you can do this as a library. In fact, this is an example use case[1] for Safe Haskell which also prevents people from circumventing your types with unsafePerformIO and friends.

Moreover, some existing libraries already take similar approaches. FRP libraries extract reactive systems (like events but also continuously changing signals) into their own types. A button gives you a stream of type Event () rather than an explicit callback system using the IO type. Check out reactive-banana[2] (my favorite FRP library from the current crop) for a nice example.

Similarly, people use custom monads to ensure things get initialized correctly, which has a similar effect to what you're talking about. The Haskell DevIL bindings for Repa[3] come to mind because they have an IL type which lets you load images and ensures the image loader is initialized correctly exactly once.

Sure, in the end, everything will need to be threaded through IO and main to actually run, but you can—and people do—make your intermediate APIs safer by creating additional distinctions between effects.

[1]: http://www.haskell.org/ghc/docs/7.8.3/html/users_guide/safe-...

[2]: http://hackage.haskell.org/package/reactive-banana

[3]: http://hackage.haskell.org/package/repa-devil

[marcosdumay]

That's great to know. Looks like I have a ton of stuff to read now.

[dllthomas]

I think there's quite a bit more of this going on than you seem to be aware of. In addition to the things mentioned in a few siblings to this comment, there is STM for software transactional memory, several different DB monads provided by persistent, Query and Update in atomic-state, Hander and Widget in yesod, Sh in shelly... In my experience, very little of my code runs in an unadorned IO monad. Some of these have holes punched in them with liftIO to let me run arbitrary IO - whether that's appropriate depends on the particular context.

[tel]

I'm currently working on a UI library similar to what you describe. When you've got a situation where "everything just ends up in IO" you probably just have an early design iteration on that space of possible libraries.

[nightski]

Generally the IO monad means "FFI". So in that sense it is very distinctive. The reason they are all lumped into IO is because they all involve FFI.

The thing is IO is generic. So IO (Db) and IO (Gui) are different things.

[wz1000]

Yes, one thing I would like to see in Haskell is more monads based on IO, but specialized to deal with specific kinds of side effects.

An example of this(not a very good one I'm afraid) is the X monad.

[Dewie]

The IO Sin Bin seems to be about the same thing that you're concerned about.

http://www.haskell.org/pipermail/haskell-cafe/2008-September...