Imagine we have a set of complex expressions. A subset of these need to be evaluated at runtime, depending on some state external to the program (e.g. user input). If these subsets are not distinct from each other then the code will likely become messy and unstructured.
What we would like to so is define all the expressions first and then pick and choose those required. This would of course involve evaluating all of the them. This wasteful of time if only a few are required.
Enter lazy evaluation! From my rather limited exposure to Haskell, I hear that lazy evaluation is all the rage. :)
Using lambdas in C# 3.0 we can create code like this:
long x = 42;
var lx = Lazy.Eval(() => x * x * x * x * x * x);
if (some_boolean_expression)
{
UseNumber(lx);
}
where UseNumber is some function that takes a "long" as input.
Now this example is over-simplified, but it shows the mechanics. We use a call to Lazy.Eval to return a wrapper around the lambda. So at that point we have not calculated the expensive expression. Later in the program the variable "lx" is used. lx is of type Lazy<long> and there exists an implicit cast from Lazy<long> to long. At this point the original expression is evaluated and saved by the lazy wrapper. So next time the value is required the cached value is returned.
Here is the Lazy<T> class:
public class Lazy<T>
{
bool _gotValue;
T _value;
Func<T> _expr;
public Lazy(Func<T> expr)
{
_expr = expr;
}
public T Value
{
get
{
if (!_gotValue)
{
_value = _expr();
_gotValue = true;
}
return _value;
}
}
public static implicit operator T(Lazy<T> l)
{
return l.Value;
}
}
And to allow the C# 3.0 compiler to infer types for us, we use a separate Lazy class:
public class Lazy
{
public static Lazy<T> Eval<T>(Func<T> expr)
{
return new Lazy<T>(expr);
}
}
Whilst lazy evaluation may not be useful in everyday programming, this example does show some of what can be achieved with lambdas in C# 3.0.