On 6/14/10 10:39, Ivan Lazar Miljenovic wrote:
By being told that using them would solve some problem you're complaining about on #haskell or the mailing lists, you look at examples, read up on them, etc.
Short version: don't worry about advanced concepts until you have to. If all else fails, it doesn't hurt to write out the low-level version yourself and then get told in a code review that it would be "easier" or more elegant with an advanced technique.
Exactly this. It's happened a few times now that I ran into a problem and then a bit later found out that feature XYZ was exactly what I needed. A feature I never understood but now suddenly had a good intuition for because it is a (or the) solution to a problem I had been thinking about for a while. But sometimes a feature looks really interesting and you really want to run into a problem to which the feature is the solution. If this is the case for you with RankNTypes, here is such a problem: 1) What's a type of this function? I say *a* type because there are multiple correct answers.
debugWith f = do putStrLn (f True) putStrLn (f 'c')
Don't ask the compiler to infer the type for you; it won't be able to. One of the characteristics of RankNTypes is that the compiler needs you, the programmer, to supply the type. 2) What would be a good argument to debugWith? 3) What's one reason the compiler can't infer the type for you? Hope this helps! Martijn.