What is a good way to design/structure large functional programs, especially in Haskell?

I&#39;ve been through a bunch of the tutorials (Write Yourself a Scheme being my favorite, with Real World Haskell a close second) - but most of the programs are relatively small, and single-purpose.  Additionally, I don&#39;t consider some of them to be particularly elegant (for example, the vast lookup tables in WYAS).

I&#39;m now wanting to write larger programs, with more moving parts - acquiring data from a variety of different sources, cleaning it, processing it in various ways, displaying it in user interfaces, persisting it, communicating over networks, etc.  How could one best structure such code to be legible, maintainable, and adaptable to changing requirements?

There is quite a large literature addressing these questions for large object-oriented imperative programs. Ideas like MVC, design patterns, etc. are decent prescriptions for realizing broad goals like separation of concerns and reusability in an OO style.  Additionally, newer imperative languages lend themselves to a &#39;design as you grow&#39; style of refactoring to which, in my novice opinion, Haskell appears less well-suited.

Is there an equivalent literature for Haskell?  How is the zoo of exotic control structures available in functional programming (monads, arrows, applicative, etc.) best employed for this purpose? What best practices could you recommend?

Thanks!

EDIT (this is a follow-up to Don Stewart&#39;s answer):

@dons mentioned: &quot;Monads capture key architectural designs in types.&quot;

I guess my question is: how should one think about key architectural designs in a pure functional language?

Consider the example of several data streams, and several processing steps.  I can write modular parsers for the data streams to a set of data structures, and I can implement each processing step as a pure function.  The processing steps required for one piece of data will depend on its value and others&#39;.  Some of the steps should be followed by side-effects like GUI updates or database queries.

What&#39;s the &#39;Right&#39; way to tie the data and the parsing steps in a nice way?  One could write a big function which does the right thing for the various data types.  Or one could use a monad to keep track of what&#39;s been processed so far and have each processing step get whatever it needs next from the monad state.  Or one could write largely separate programs and send messages around (I don&#39;t much like this option).

The slides he linked have a Things we Need bullet: &quot;Idioms for mapping design onto 
types/functions/classes/monads&quot;.  What are the idioms? :)


All Large Scale Solutions on Gang of Coders

Total of 1 Large Scale Solutions

Large-scale design in Haskell?