Robert Heumüller
I've added the type signatures. What's next?
Great, now that makes it much easier to reason about performance. A quick look at the type signatures tells me that your next step is to use the right tool for the job. In Haskell this basically means to use the right data and control structures. First of all know when not to use lists. A good intuition is to ask yourself whether the lists will actually live in memory. If no, then lists are fine. If yes (like in your case), examine your usage. If you use them like stacks (working on the head only) that's probably fine (it's not in your case). However, if you fold and unfold a lot or index individual elements you probably want a different data structure like a vector or a map. This is a somewhat involved topic and needs a lot of training, but making the right decision here will give you the main performance boost. Note: Whatever you do, stay in pure land. Always use immutable data structures. If your code is too slow, you may be using the right data structure the wrong way. Going mutable is almost always the wrong way. Again: It takes some training, especially in Haskell where (as a beginner) you may not see directly what is actually happening. Also find spots where sharing can be used. Unshared example: f x' + f x' Shared version: let x = f x' in x + x Haskell compilers don't do that automatically for you, because sharing trades memory for run-time performance, and the outcome is hard to predict for a compiler. I suggest experimenting. Greets, Ertugrul -- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad.