[Haskell-beginners] Re: learning to use Haskell types

[Heinrich Apfelmus]

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