I’ve written an add-in for Visual Studio called Ora. You can read more about it via that link but here’s some background to it.
It’s designed to replace a common use of regions – though I’d call it a common abuse of regions – so it’s called Ora, which means a bunch of things in various languages, but can mean region in Latin.
Regions are a feature of C# that generate some controversy, inevitably known as the region wars.
The Maybe Monad is extremely simple. It represents a value that might be there, but might not, and also provides a neat way of working with such values.
This Haskell-related page makes it pretty clear:
The Maybe monad embodies the strategy of combining a chain of computations that may each return
Nothingby ending the chain early if any step produces
Nothingas output. It is useful when a computation entails a sequence of steps that depend on one another, and in which some steps may fail to return a value.
Change Nothing to null and we’re talking in C#. Furthermore, it advises:
Linq lets you think in a very generally applicable way and solve a very wide variety of problems with a few key concepts. That’s a great thing. But it’s irritating when the elegant solution doesn’t perform as well as an ugly special case.
Using a combination of well-known Linq features I’m going to demonstrate that we already have the power to get the best of both worlds: speed and elegance.
One example that has always irked me (and which is simple enough to demonstrate the idea with) is this:
The idea of returning functions via yield return to simply asynchronous IO programming has a precedent in Microsoft’s Concurrency and Coordination Runtime:
Although they are yielding interfaces, really they are yielding functions:
The ITask interface has only one really important method: Execute, which means that really it’s a function (a delegate in C# terms). I think the functional style makes the whole thing cleaner, but the point is that the idea was already in use in the Microsoft’s CCR, perhaps as long ago as 2005 (although that’s difficult to verify).
If you do asynchronous programming (or have been put off it in the past by the complexity) and you haven’t already looked at this, then you really should:
I blogged yesterday about an idea for doing the same kind of thing but using lambdas to encapsulate the last remaining bit of complexity. Today I’ve applied the same idea, but with the goal of providing a thin layer that works along with Jeffrey Richter’s AsyncEnumerator class, essentially providing an optional new way of working with it. As I am not especially familiar with the asynchronous APIs, it would be especially stupid for me to try and reinvent the wheel instead of building on the work Jeffrey has already done.
Update: More in-depth stuff about this
I just watched this video of Jeffrey Richter demonstrating his AsyncEnumerator class:
The key idea is the realisation that yield return takes care of turning a single function into a continuation that can be resumed under the control of some other code, but still provides a natural way to write procedurally. This is just what is needed to manage asynchronous communication. Great stuff.