Are you talking about Parser combinators? haskell [http://www.haskell.org/haskellwiki/Parsec] and F#'s FParsec [http://www.quanttec.com/fparsec/]?
As for global type inference the one in F# is only partially global (between Scala and ML , Haskell). Anytime you are dealing with ad-hoc polymorphism, even when F# has inferred the types, you will often have to put the type in. Full point free programming also does not always resolve if you are into that.
I have gotten into the habit of putting types and names for complicated functions in comments (///). I also write short descriptions for particularly dense pieces of code and have gotten in the habit of writing clearer, less dense code with full names because otherwise it does take longer to mentally unpack. That is, functional languages make it easy to write stuff like: let wu wp wn nu y x = wp * (exp (nu * y * x)) , wn * (exp (-nu * y * x))
- F# doesn't have tool support for _building_ UIs (e.g., Winforms designer), but beyond that, it's very good for the code which actually runs the UI (the eventing and so forth).
- You could build some functions to manipulate fragments from XML, then build some higher-level functions from those, etc., then traverse your data (whatever it is) and use the functions you've built to emit XML in a clean and _precise_ way. I think Haskell already has such a library -- perhaps someone's ported it to F#?
- You can use F# 'async' workflows to retrieve data from web APIs really easily (and quickly, if you are doing it in bulk). In fact, this is probably one of the most common code examples shown for async workflows.
In my experience, F# isn't great at everything, but in general, I'm much, much more productive writing F# than I ever was/am in C#.