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.
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
