...and why should I care?
Every time computation expressions in F# are discussed it's only a matter of time before the dreaded Mword is mentioned. So let's get it out of the way early....
Monad
Right, that's that done and let's not mention it again. Suffice to say, they're an interesting concept with no equivalent in C# and no necromancy is required to use or make them.
If you've done any async work in F# or anything involving sequences then odds are you've already used a computation expression (CE).
let mySequence =
seq {
"First Item"
"Second Item"
}
let myAsyncThing =
async {
let! result = DoTheAsyncThing
return result
}
The F# compiler has no builtin tricks or optimisations for these, they're just plain computation expressions, just like you can write too!
Every computation expression needs a backing builder class, usually named after the computation, so async
would have a builder of type AsyncBuilder
. All it has to do to be used as a CE is implement certain methods, which map to particular keywords inside a CE.
Method  Typical signature(s)  Description 

Bind  M<'T> * ('T > M<'U>) > M<'U> 
Called for let! and do! in computation expressions. 
Delay  (unit > M<'T>) > M<'T> 
Wraps a computation expression as a function. 
Return  'T > M<'T> 
Called for return in computation expressions. 
ReturnFrom  M<'T> > M<'T> 
Called for return! in computation expressions. 
Run 
M<'T> > M<'T> or M<'T> > 'T

Executes a computation expression. 
Combine 
M<'T> * M<'T> > M<'T> or M<unit> * M<'T> > M<'T>

Called for sequencing in computation expressions. 
For 
seq<'T> * ('T > M<'U>) > M<'U> or seq<'T> * ('T > M<'U>) > seq<M<'U>>

Called for for...do expressions in computation expressions. 
TryFinally  M<'T> * (unit > unit) > M<'T> 
Called for try...finally expressions in computation expressions. 
TryWith  M<'T> * (exn > M<'T>) > M<'T> 
Called for try...with expressions in computation expressions. 
Using  'T * ('T > M<'U>) > M<'U> when 'T :> IDisposable 
Called for use bindings in computation expressions. 
While  (unit > bool) * M<'T> > M<'T> 
Called for while...do expressions in computation expressions. 
Yield  'T > M<'T> 
Called for yield expressions in computation expressions. 
YieldFrom  M<'T> > M<'T> 
Called for yield! expressions in computation expressions. 
Zero  unit > M<'T> 
Called for empty else branches of if...then expressions in computation expressions. 
Quote  Quotations.Expr<'T> > Quotations.Expr<'T> 
Indicates that the computation expression is passed to the Run member as a quotation. It translates all instances of a computation into a quotation. 
Now that all looks complicated so let's take a quick look at what advantages a CE gives us over writing plain code.
Let's consider an example where we need to pass an item through several validation checks
let itemToValidate = SomeThingThatNeedsValidating()
// Each validation methhod has signature Item > Result<Item, Error>
let firstValidation = firstValidationCheck itemToValidate
let secondValidation =
match firstValidation with
 Error e > e
 Ok item > secondValidationCheck item
let thirdValidation =
match secondValidation with
 Error e > e
 Ok item > thirdValidationCheck item
You probably look at that and think there must be a better way to write that. And you'd be right, this is a great example where we can use a computation expression.
To build it, let's look at the Result
type and see if it has anything that can help us.
There is already a Result.bind
that does the same as the match
statements above, so let's use that instead of reinventing the wheel.
type ResultBuilder() =
// This can be used in a CE via the let! keyword
// Result<'a,'b> * ('a > Result<'c,'d>) > Result<'c,'d>
member __.Bind(r, f) = Result.bind f r
// This can be used in a CE via the return keyword
// 'a > Result<'a, 'b>
member __.Return(x) = Ok x
// This exposes the builder type as a computation expression
// It's what allows to use it like below...
let result = ResultBuilder()
Short, sharp and to the point, right? But now we can express the validation checks above like this...
let itemToValidate = SomeThingThatNeedsValidating()
let validatedItem =
result { // result here is the created instance of ResultBuilder from above
let! firstCheck = firstValidationCheck itemToValidate
let! secondCheck = secondValidationCheck firstCheck
let! thirdCheck = thirdValidationCheck secondCheck
return thirdCheck
}
The beauty of this approach is that the let!
keyword will only bind the successful validation and allow the CE to continue evaluating. If an error is returned from any of the validation checks then the entire CE will short circuit and return that error immediately.
Congratulations, you now have a basic working CE of your very own! But a lot of that code looks like we shouldn't need it. Why assign each intermediate result to a variable along the way, surely we should just be able to pipe each step in to the next, right?
Let's add two further items to where we create our ResultBuilder
// F# allows us to define our own operators
// By convention, >>= usually refers to a bind method
let (>>=) result binder = Result.bind binder result
type ResultBuilder() =
// This can be used in a CE via the let! keyword
// Result<'a,'b> * ('a > Result<'c,'d>) > Result<'c,'d>
member __.Bind(r, f) = Result.bind f r
// This can be used in a CE via the return keyword
// 'a > Result<'a, 'b>
member __.Return(x) = Ok x
// This can be used in a CE via the return! keyword
// Result<'a, 'b> > Result<'a, 'b>
member __.ReturnFrom x = x
let result = ResultBuilder()
Now we can chain together our validation checks and it becomes a lot easier to be able to add new checks, compose smaller ones together, or reorder them without having to rename every variable along the way.
let itemToValidate = SomeThingThatNeedsValidating()
let validatedItem =
result {
return!
firstValidationCheck itemToValidate
>>= secondValidationCheck
>>= thirdValidationCheck
}
Now if we found we needed an extra check that should be between secondValidationCheck
and thirdValidationCheck
, it is as simple as adding it in.
Hopefully this has helped to show you the power of a computation expression and that they aren't as scary as they first seemed. Of course this was a relatively simple example but from here you can see how they can be extended with additional functionality and even custom keywords that can be used to create miniature programming languages to solve problems. More to come on that front....
Discussion (0)