There are some books that go over using functional programming for "real world" tasks. Two off of the top of my head are Real-World Functional Programming by Tomas Petricek and Jon Skeet (.NET focused, and might be a bit aged now), and Real World Haskell (http://book.realworldhaskell.org/). So indeed, there are resources to help answer this question by walking you through common things like drawing graphs, database querying, working with XML, etc.
I've given F# a try recently for some of those tasks, and while it certainly is very capable of accomplishing them, I've found that using the .NET libraries, or having to expose my own APIs to C# developers in a way that will be natural to them, often leads me to simply writing C# with F#'s syntax. This is certainly no worse than having done so in C# directly, but the core ideas behind functional programming just seem to get diluted. On a side note, I think that with a bit of more design in mind, it should be possible to at least keep the core components 'functional' and then just have a middle layer that defines the classes and handles interop so your code can then be used from C# in an OO way.
Can you give an example? I have found this is only the case in a small part to do with initializing the structure. Working with Active patterns and monads can turn OO code more functional.
As for exposing I write in a typical functional ways then provide wrappers. But these days even non wrapped code can be trivially consumed from C#.
My most recent "meh" styled F# script had to parse 16MB of ugly XML that contained values which even unicode did not define. The goal was to create a lookup structure based on this data that could then be used from C#. I used seq expressions for cleaning up the input stream, active patterns for parsing the XML, but felt that I had no other choice than to use classes with dictionary members for the lookup data structure. With well over 100,000 items to organize and store, I did not want the overhead of creating a functional structure that would then have to be converted to nested Dictionaries for C# use. Anyway, at that point it became kind of pointless to try and avoid an imperative approach to populating the data structure.
I've given F# a try recently for some of those tasks, and while it certainly is very capable of accomplishing them, I've found that using the .NET libraries, or having to expose my own APIs to C# developers in a way that will be natural to them, often leads me to simply writing C# with F#'s syntax. This is certainly no worse than having done so in C# directly, but the core ideas behind functional programming just seem to get diluted. On a side note, I think that with a bit of more design in mind, it should be possible to at least keep the core components 'functional' and then just have a middle layer that defines the classes and handles interop so your code can then be used from C# in an OO way.