Michael Mossey wrote:

This is really a general question, but any advice is welcome.

I'm currently working through Typeclassopedia and all the tutorials it links to. I'm really enjoying it, but a kind of scary question is: when I begin to write "real" software in Haskell, how will I find natural places to use the types and how will I make the transition to idiomatic Haskell?

[...]

Then it occurred to me that a common theme in Haskell is to provide a way to express a solution to a problem in an expressive form that is natural to that problem. So maybe what I need to do is stop thinking, "Where can I use this type," and instead dream up ways to express ideas in a simple and natural form, then make use of Haskell types and type classes to make that expressive form a reality.

Yes, that's the best approach. The hard part is finding a formulation that is natural to the problem; and by definition it's hard to give general advice there. I know of no other way than learning from examples, like this one Simon Peyton Jones, Jean-Marc Eber, Julian Seward. "Composing contracts: an adventure in financial engineering" http://research.microsoft.decenturl.com/composing-contracts What the Typeclassopedia can help with is to provide a few known concepts where it's always worth checking whether they apply naturally. I'd recommend the following order Monoid | | Applicative Monad | Arrow In particular, Monoids are very common. The others usually only apply when the problem domain involves polymorphism, i.e. when the object of discourse is a type constructor. That being said, the many concrete applicative functors and monads like state monads, the list monad, zip lists, parser combinators, probabilistic monads etc. are very useful implementation techniques. But they are limited to "small scale" simplifications, they generally do *not* help with finding a formulation that is natural to the whole problem domain. (Except when it's very obvious, i.e. when the problem *is* to model a state machine, to parse something, to sample a probability distribution, etc.)

For example, in a music editor, there are many actions that create new notes. A note needs many pieces of information to describe it: the note's place in time, its duration, dynamics, whether tied to successive notes, type of flag or beam... Much of this information can be inferred from the context in which the note is created, and so a natural expressive language would bring a new note into existence with a minimal need for providing details. Those details would be inferred from the context. So that's a Reader monad right there.

This would be an example where I think that the Reader monad is an implementation detail, not a model of the problem domain. (Not to mention that I think that the Reader monad has very limited applications.) The latter would be about trying to eliminate the need for a context altogether, to group the many details so that they can be "polymorphized away", etc. Regards, apfelmus -- http://apfelmus.nfshost.com