If you're looking for a project to take on, I would suggest starting with the following:

A high-level, type-safe AMQP client written in 100% Haskell, which provides a clean way of handling hundreds of unique message types.

Then it would be possible to hook it up to any AMQP broker (most likely RabbitMQ). There are logical steps beyond the above (an embedded Haskell broker), but the above project is far from trivial. And the main undertaking, I think, consists not in coding to the spec (for which there is some help; a JSON representation of the AMQP specification can be processed and used to emit language-specific code), but in finding a design that works well in Haskell.

Regards,

John

On Jan 8, 2009, at 1:16 PM, Creighton Hogg wrote:

On Thu, Jan 8, 2009 at 2:02 PM, John A. De Goes <john@n-brain.net> wrote:

On Jan 8, 2009, at 12:56 PM, Tim Newsham wrote:

You replied to someone discussing using Haskell at a CDN to implement

things like web servers by saying that Haskell wasn't suitable for

the task.

That is incorrect. I replied to Achim's message asking for elaboration on

Haskell's unsuitability. It was a convenient point to discuss Haskell's

networking deficiencies.

Part of the problem I'm having with this discussion, though, is that

it's still not clear to me what critical features are lacking. I know

you've said Haskell doesn't have anything quite like the Erlang OTP

library, but that doesn't really help me much. I've only looked a

little at OTP & I don't think I understand what you get from its

behaviors that you don't get from Control.Concurrent + mtl, i.e.

various forms of state & error handling independent of the concurrency

underneath.

Can you elucidate a bit more? I don't want the conversation to degenerate.