Hi,
"computation expressions" in F# are very similar to "monads", but that's not very useful analogy, because monads in Haskell have a different primary purpose. You already mentioned some examples - sequence comprehensions (seq { }), AttemptBuilder example (attempt { }), but there are also asynchronous workflows (async { }).

What they all share is that the code embedded in the "computation expressions" can be written in usual F# code, so the expression represents some executable code. However, all of them are not "standard" code. "Seq" because it can return multiple values on demand, "attempt" because it may fail and execute only part of the code, "async" because the rest of the code executes after asynchronous call is completed.

So, the short answer is that they allow us to write code that runs in a "non-standard" way. Of course, all the code needs to access "usual" F# code and that's why we have "let" and "let!" (or "do" and "do!"). The version with exclamation mark can be used for calling other non-standard code of the same type, while the ordinary "let" just executes ordinary F# code.

In C#, you can write two kinds of non-standard computaions. Brian already mentioned LINQ expressions, where you can use (somewhat limited) C# language for writing body of some code that manipulates with collections (that's similar to "seq { }"). However, C# 2.0 also has "iterators" and the "yield return" keyword, which is another way for writing non-standard computations for working with collections - again, you can return multiple values, so it is similar to "seq { }".

Interestingly, it is posible to use C# "yield return" to emulate "async { }" from F#. You can find more information here: [link:tomasp.net]

Hope this helps!
T.

I know where you are coming from as I have both Expert F# and Foundations of F#. I have had to read the Workflow section over and over and it is still not clear.

I am trying to understand FP and I have blogged about functions and monoids - I am almost done with the monad section [[link:sdasrath.blogspot.com] It is under the Functional Programming tag.

In terms of monads, from what I understand, is that in order to do useful work in programming, you have to have side effects, such as IO. In a purely functional environment, there are no side effects but monads and workflows allow for side effects to take place. The whole idea behind workflow/monad is to take simple expressions, have a way of combining them and build even more complex expressions.

I like to think of monads as lego blocks. Individual blocks are simple and not very useful - however, by combining several of these simple blocks togther, you can make a more complex object.

OK I am not sure if there is an exact parallel of Workflows to something in C# but in terms of F#, workflows are like an extension of Sequence Expressions where you can either return a value (via the yield keyword) or return another sequence which can be used for further processing (via the yield! keyword).

I realized I have not fully answered your questions, but I hope that at least the monad thing is at least a little bit clearer. We are both battling workflows it seems (and also Language Oriented Programming in my case!)

I am sure either D. Syme or R. Pickering at the very least will shed some more light on the matter.
~sparky

I will only partly answer the question (hopefully the 'easier' part)...

1) "LINQ" is the best fill-in-the-blank, though it is a bit misleading because LINQ in C# was designed with a very targeted domain in mind (querying _sequences_ using monadic comprehensions), whereas the F# computation expressions are a bit more general.

1.1) This pretty much translates to 'what are monads good for', and the answer, briefly, is that they can be applied in many disparate and apparently unrelated domains, which makes it very hard to sum up what monads actually are (because what they all have in common is very abstract; hard to see commonality via disparate examples). I hope to blog more about this over the coming months, but I find it very hard to write good understandable prose on the topic.

2) There is 'magic'; it is very much the same kind of magic as in C# LINQ and C# enumerators. In LINQ in C#, if you happen to add the right methods (e.g. Select, SelectMany, ...) with the right signatures to a data type, the language recognizes it and some new keywords 'light up' for that data type. The exact same thing happens with F# computation expressions, you just need the right 'structural fit' (but don't need inheritance) with various methods (Bind, Return, ...) and the computation expression syntax 'lights up' for a new type. (A similar kind of thing happens for enumerables, any type with the right signature GetEnumerator() can be used in a foreach, even if the object doesn't implement IEnumerable - this is one of the dustier corners of C# that many people aren't aware of.) Note that unfortunately I think it's hard to explain the motivation/reasoning behind these special language rules without having a good understanding of the answer to 1.1 first.