Jomo Fisher -- Sharp Things : .NET Futures

F# Scripting, .NET 4.0 and Mixed-mode assemblies

Jomo Fisher — Tue, 17 Nov 2009 20:32:38 GMT

Jomo Fisher—There is a nice F# and DirectX demo that has been floating around for a while now. A recent version can be found here: http://code.msdn.microsoft.com/fsharpsamples/Wiki/View.aspx?title=Home&version=2

One of the recent problems we’ve seen is that, because of the support for side-by-side runtimes, .NET 4.0 has changed the way that it binds to older mixed-mode assemblies. These assemblies are, for example, those that are compiled from C++\CLI. Currently available DirectX assemblies are mixed mode. If you see a message like this then you know you have run into the issue:

Mixed mode assembly is built against version 'v1.1.4322' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information.

Though you may see it in the F# interactive, this message originates as an exception in the .NET 4.0 runtime. You may also see the message if you recompile a C#, VB or F# application that uses DirectX or other mixed-mode assembly against the .NET 4.0 runtime.

The good news for applications is that you have the option of falling back to .NET 2.0 era binding for these assemblies by setting an app.config flag like so:

<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0"/>
</startup>

Things get a little trickier for scripts, though, since there is no .exe running. Here is a little snippet of code you can run in the F# repl to switch to 2.0 binding mode:

open System

open System.Runtime.InteropServices

open System.Runtime.CompilerServices

[<ComImport>]

[<InterfaceType(ComInterfaceType.InterfaceIsIUnknown)>]

[<Guid("BD39D1D2-BA2F-486A-89B0-B4B0CB466891")>]

type ICLRRuntimeInfo =

    // vtable slots

    abstract xGetVersionString : unit -> unit

    abstract xGetRuntimeDirectory : unit -> unit

    abstract xIsLoaded : unit -> unit

    abstract xIsLoadable : unit -> unit

    abstract xLoadErrorString : unit -> unit

    abstract xLoadLibrary : unit -> unit

    abstract xGetProcAddress : unit -> unit

    abstract xGetInterface : unit -> unit

    abstract xSetDefaultStartupFlags : unit -> unit

    abstract xGetDefaultStartupFlags : unit -> unit

    [<MethodImpl(MethodImplOptions.InternalCall, MethodCodeType=MethodCodeType.Runtime)>]

    abstract BindAsLegacyV2Runtime : unit -> unit

let rtInfo = RuntimeEnvironment.GetRuntimeInterfaceAsObject(Guid.Empty,typeof<ICLRRuntimeInfo>.GUID) :?> ICLRRuntimeInfo

rtInfo.BindAsLegacyV2Runtime()

This needs to be the first thing that runs in your interactive window.

This posting is provided "AS IS" with no warranties, and confers no rights.

F# Performance Tweaking

Jomo Fisher — Tue, 16 Sep 2008 21:14:00 GMT

Jomo Fisher—I’ve enjoyed reading the blog series on F# and game development here. Joh had posted an example of F# of using RK4 and showed some performance numbers comparing F# to C++ and OCaml. Don Syme had been reading too and asked if anyone on the F# team wanted to take a stab to see if they could optimize Joh’s code any further. I thought it would be fun. It turns out there were a few small changes that make a significant performance improvement without sacrificing immutability or other nice functionalness.

The example code in this article was compiled with the 1.9.6.2 version of the F# compiler.

Joh probably already accounted for this, but it’s worth pointing out that there is a huge performance difference between Debug and Release builds for this example. On my machine I could measure a 3x performance difference between the two.

Considering just Release builds, I was able to get another 2-3x improvement by making several simple changes:

- Change a few functions to return struct instead of tuple. For this, I created a ps (e.g. Position-Speed) struct and a sa (e.g. Speed-Acceleration) struct.

- I manually lifted a few computations out of the outer similar loop. I made (euler_implicit_opt accel_opt) and (runge_kutta_4_opt (adapt_opt accel_opt))into values.

- I changed the simulate function to use OptimizedClosures.FastFunc3.

This last part especially needs some explaining. Closure optimization can be used when a function will be called many times. It allows F# to do a bit of expensive work up front that will later be amortized across the many calls to the function. Below is the simulate function using optimized closures. I’ve bolded the affected lines.

let inline simulate_opt intg_func t0 t_fin delta pos0 speed0 =

let oc = OptimizedClosures.FastFunc3<_,_,_,_>.Adapt(intg_func)

let rec repeat t0 pos0 speed0 =

if t0 > t_fin then (pos0, speed0)

else

let t1 = t0 + delta

let ps:ps<_> = oc.Invoke(pos0,speed0,delta)

repeat t1 ps.pos ps.speed

repeat t0 pos0 speed0

Unfortunately, this is not something that you can stick everywhere and just get a benefit (otherwise, the compiler could just inject it for you). You should definitely profile before and after. Here are my final performance numbers:

Optimized---

Euler single: 2.529253

Euler multi: 1.328133

RK4 single: 2.383238

RK4 multi: 1.241124

Baseline---

Euler single: 7.672767

Euler multi: 3.922392

RK4 single: 4.563456

RK4 multi: 2.450245

Here’s the entire code. The optimized functions end in _opt. Thanks Joh for an awesome diversion!

#light

open System

let run_time_func (func: unit -> 'a) =

let time0 = System.DateTime.Now

let res = func ()

let diff0 = System.DateTime.Now - time0

(diff0, res)

let map_parallel func items =

let tasks =

seq {

for i in items -> async {

return (func i)

}

Async.Run (Async.Parallel tasks)

let gravity =

-9.81

let inline spring pos =

let k = 100.0 in

-k * pos

let inline drag k pos speed = -k * speed

type ps<'num> = struct

val pos:'num

val speed:'num

new(pos,speed) = {pos=pos;speed=speed}

end

type sa<'num> = struct

val speed:'num

val accel:'num

new(speed,accel) = {speed=speed;accel=accel}

end

let inline euler_implicit accel_func pos speed delta =

let speed2 = speed + delta * accel_func pos speed in

pos + delta * speed2, speed2

let inline euler_implicit_opt accel_func pos speed delta =

let speed2 = speed + delta * accel_func pos speed in

ps(pos + delta * speed2, speed2)

let inline adapt (f: 'num -> 'num -> 'num) =

fun pos speed ->

let accel = f pos speed in

speed, accel

let inline adapt_opt (f: 'num -> 'num -> 'num) =

fun pos speed ->

let accel = f pos speed in

sa(speed, accel)

let inline runge_kutta_4 deriv_func pos speed delta =

let half_delta = 0.5 * delta

let s1, a1 = deriv_func pos speed

let s2, a2 = deriv_func (pos + half_delta * s1) (speed + half_delta * a1)

let s3, a3 = deriv_func (pos + half_delta * s2) (speed + half_delta * a2)

let s4, a4 = deriv_func (pos + delta * s3) (speed + delta * a3)

let pos1 = pos + delta/6.0*(s1 + 2.0*s2 + 2.0*s3 + s4)

let speed1 = speed + delta/6.0*(a1 + 2.0*a2 + 2.0*a3 + a4) in

pos1, speed1

let inline runge_kutta_4_opt deriv_func pos speed delta =

let half_delta = 0.5 * delta

let sa1:sa<_> = deriv_func pos speed

let sa2 = deriv_func (pos + half_delta * sa1.speed) (speed + half_delta * sa1.accel)

let sa3 = deriv_func (pos + half_delta * sa2.speed) (speed + half_delta * sa2.accel)

let sa4 = deriv_func (pos + delta * sa3.speed) (speed + delta * sa3.speed)

let pos1 = pos + delta/6.0*(sa1.speed + 2.0*sa2.speed + 2.0*sa3.speed + sa4.speed)

let speed1 = speed + delta/6.0*(sa1.accel + 2.0*sa2.accel + 2.0*sa3.accel + sa4.accel) in

ps(pos1, speed1)

let inline simulate intg_func t0 t_fin delta pos0 speed0 =

let rec repeat t0 pos0 speed0 =

if t0 > t_fin then (pos0, speed0)

else

let t1 = t0 + delta

let pos1, speed1 = intg_func pos0 speed0 delta

repeat t1 pos1 speed1

repeat t0 pos0 speed0

let inline simulate_opt intg_func t0 t_fin delta pos0 speed0 =

let oc = OptimizedClosures.FastFunc3<_,_,_,_>.Adapt(intg_func)

let rec repeat t0 pos0 speed0 =

if t0 > t_fin then (pos0, speed0)

else

let t1 = t0 + delta

let ps:ps<_> = oc.Invoke(pos0,speed0,delta)

repeat t1 ps.pos ps.speed

repeat t0 pos0 speed0

let initial_states = [ for s in 1..1000 -> (float s * 1.0, 0.0) ]

let t0 = 0.0

let t_fin = 1000.0

let delta = 0.025

let accel pos speed = (drag 1.0) pos speed + spring pos + gravity in

let accel_opt pos speed = (drag 1.0) pos speed + spring pos + gravity in

let ef = (euler_implicit_opt accel_opt)

let rk4f = (runge_kutta_4_opt (adapt_opt accel_opt))

// Changes

// - Change euler_implicit_opt and runge_kutta_4_opt to return a struct (ps)

// - Manually lift (euler_implicit_opt accel) and (runge_kutta_4_opt (adapt accel)) out of loop

// - Change adapt_opt to return struct (sa)

// - Use optimized closure in simulate_opt

printfn "Optimized---"

for i in 0..0 do

let (run_time, res) = run_time_func (fun () -> initial_states |> List.map(fun (x,y) -> simulate_opt ef t0 t_fin (0.25*delta) x y))

printfn "Euler single: %f" run_time.TotalSeconds;

let (run_time, res) = run_time_func (fun () -> initial_states |> map_parallel(fun (x,y) -> simulate_opt ef t0 t_fin (0.25*delta) x y))

printfn "Euler multi: %f" run_time.TotalSeconds;

let (run_time, res) = run_time_func (fun () -> initial_states |> List.map(fun (x,y) -> simulate_opt rk4f t0 t_fin delta x y))

printfn "RK4 single: %f" run_time.TotalSeconds;

let (run_time, res) = run_time_func (fun () -> initial_states |> map_parallel(fun (x,y) -> simulate_opt rk4f t0 t_fin delta x y))

printfn "RK4 multi: %f" run_time.TotalSeconds;

printfn "Baseline---"

for i in 0..0 do

let (run_time, res) = run_time_func (fun () -> initial_states |> List.map(fun (x,y) -> simulate (euler_implicit accel) t0 t_fin (0.25*delta) x y))

printfn "Euler single: %f" run_time.TotalSeconds;

let (run_time, res) = run_time_func (fun () -> initial_states |> map_parallel(fun (x,y) -> simulate (euler_implicit accel) t0 t_fin (0.25*delta) x y))

printfn "Euler multi: %f" run_time.TotalSeconds;

let (run_time, res) = run_time_func (fun () -> initial_states |> List.map(fun (x,y) -> simulate (runge_kutta_4 (adapt accel)) t0 t_fin delta x y))

printfn "RK4 single: %f" run_time.TotalSeconds;

let (run_time, res) = run_time_func (fun () -> initial_states |> map_parallel(fun (x,y) -> simulate (runge_kutta_4 (adapt accel)) t0 t_fin delta x y))

printfn "RK4 multi: %f" run_time.TotalSeconds;

done;

T his posting is provided "AS IS" with no warranties, and confers no rights.

LINQ to SQL Beta2 Performance Numbers and the Dynamic Compilation Pattern

Jomo Fisher — Fri, 06 Jul 2007 18:42:00 GMT

Jomo Fisher--Rico Mariani has been posting about LINQ to SQL perfomance and has finally posted the performance numbers for Beta2: http://blogs.msdn.com/ricom/archive/2007/07/05/dlinq-linq-to-sql-performance-part-4.aspx

One of the tricks Rico and Matt Warren used to get this stellar performance was to generate IL at run time. I learned this design pattern from Matt and used it on a completely different problem (see http://blogs.msdn.com/jomo_fisher/archive/2007/03/28/fast-switching-with-linq.aspx) to get a 900% performance improvement. I don't know whether this pattern already has a name (Dynamic Compilation seems to fit) but it's hard to ignore its potential for significant performance improvement in a particular class of problem. A further benefit is that you can hide a lot of complex, deep thinking code behind a simple interface that you present to your user.

Correction: Now that I think about it, I may have originally learned this pattern from my high school friend Brandon D'Souza who used it to compile equations into Apple II machine language. This was for a spread sheet application our teacher wanted to call 'Rickards High Scool 1-2-3-4.'

This posting is provided "AS IS" with no warranties, and confers no rights.

Why Symmetric Multicore is a Dead End for PCs

Jomo Fisher — Mon, 25 Jun 2007 20:48:00 GMT

Jomo Fisher--There are two kinds of programming problems—those that can run in parallel and those that can’t. There’s no special sauce that can turn an inherently serial problem into an efficient parallel algorithm. Today’s top-end desktop has eight cores spread across two processors. All of the cores are identical and they’re each as fast and feature-rich as their manufacturer can make them.

For the algorithms that can’t run in parallel, having eight cores is like trying to get your Christmas shopping done faster by strapping eight Ferraris together and driving them from store to store. Eventually you’ll give up and just use the one with the most gas in the tank.

On the other hand, for problems that can be run in parallel, it’s better to have many processors than to have a small number of very fast processors. Think of sending out a hundred robot minions on Vespas to Christmas shop for you.

Now imagine a world in which you have one very fast processor and a bunch of smaller slave processors. (author takes out napkin and crayon and starts madly scribbling). Let’s say the smaller ones are just good enough to host something like the .NET runtime or a C++ runtime and to execute a few concurrent ui-less processes. They communicate with each other using relatively slow TCP\IP, they have a modest amount of non-shared read-write RAM (let’s say 256meg), and they have a modest amount of shared read-only RAM so that each doesn’t need its own copy of the runtime. There would need to be an onboard TCP\IP switch to keep the communication relatively snappy.

Let’s crunch some numbers. Today’s Core 2 Quad has 582 million transistors. Let’s say our scaled down Vespa CPU is 21 million transistors—this is half the size of a P4 but maybe still too large for what I have in mind. For simplicity, let’s say our onboard dedicated TCP\IP switch is 10 million transistors—I know this is overkill but let’s just use it for a first-order approximation.

So, for the same cost as today’s top-end we could have 1+48 cores that will run single-threaded code as well as today’s systems and, for parallel problems, is significantly better. Now that’s a machine I’d like to find under my Christmas tree this year.

Update August 23, 2007--I just noticed this. It looks like some smart folks were already busy working on such a thing. Now if we could just get the .NET framework running it>>>

This posting is provided "AS IS" with no warranties, and confers no rights.

Dealing with Linq’s Immutable Expression Trees

Jomo Fisher — Wed, 23 May 2007 23:37:00 GMT

Jomo Fisher --I recently got a question via my blog that dovetailed nicely with something I’ve been working on:

I know that expression trees are (or at least appear to be) immutable - which requires that you rewrite the entire tree if you want a tree that is similar, but not the same as, an existing tree.

My questions is really whether there is anything in the near term pipeline from Microsoft that might address this gap.

Linq’s expression trees are indeed immutable. I’ve worked with mutable trees—LINQ to SQL has an internal tree structure that’s mutable—and immutable trees like expression trees from the System.Linq.Expression namespace. I’ve really come to believe that, maybe counter-intuitively, immutable trees are far easier to work with. See this blog article for a discussion of the sorts of problems that can arise with mutable classes.

The problems are actually magnified when a tree structure is mutable because they’re intrinsically more complex and because it’s easy to unintentionally turn the tree into a graph. This latter problem is relieved in immutable trees because a node must exist before it can be assigned to be the child of another node.

Another advantage of immutable trees is that you can effectively duplicate them just by reference assignment. Here’s what I mean:

Expression<Func<int, int>> f = (n => 1 - n);

Expression<Func<int, int>> g = f;

f = MyRewriteFunction(f);

Here, the variable ‘g’ keeps the original expression tree value while ‘f’ is rewritten with a new value. Notice that this is a very fast reference copy. Without the immutability guarantee you would have to physically copy the tree to get the same guarantee.

Changing a Mutable Tree without Complete Rewrite

This original concern, though, is about the need to completely rewrite the tree in order to change it. It turns out, though, that you only need to rewrite the slice of the tree from the point of the change along with parents all the way to the root expression. While you do need to recreate the parents you can reuse the unchanged siblings. This is actually a very powerful concept:

You can create a forest of similar expression trees in which only the differences between the trees occupy extra memory.

For example, if you have a system that rewrites an expression tree in many phases then you can keep all of the intermediate rewrite steps with little effort and without consuming unnecessary memory.

Another example might be a Genetic Programming example in which the mutations are kept in a forest of expression trees.

Yet another example might be a theorem prover in which you need to search for a particular tree but you need to be able to backtrack if you reach a dead end.

I should back this up with an example. My example is based on the chain-of-responsibility code that I posted here. You’ll need that code to make this work. What we need is a visitor over Linq Expression trees. This visitor needs to recognize when a child node has changed and rewrite parent nodes all the way to the root.

(Note: This is is post-Beta1 code and won't compile with Beta1 and earlier of Orcas. At the bottom, I've attached the equivalent Beta1 ExprOp class and sample code).

public static class ExprOp {

static public Func<Expression, Expression> Visit = FuncOp.Create<Expression, Expression>(

(self, expr) => {

switch (expr.NodeType) {

case ExpressionType.Coalesce:

var c = (BinaryExpression)expr;

var left = self(c.Left);

var right = self(c.Right);

var conv = self(c.Conversion);

return (left == c.Left && right == c.Right && conv == c.Conversion) ? expr : Expression.Coalesce(left, right, (LambdaExpression)conv);

case ExpressionType.TypeIs:

var tbe = (TypeBinaryExpression)expr;

var tbex = self(tbe.Expression);

return (tbe.Expression == tbex) ? expr : Expression.TypeIs(tbex, tbe.TypeOperand);

case ExpressionType.Conditional:

var ce = (ConditionalExpression)expr;

var t = self(ce.Test);

var it = self(ce.IfTrue);

var @if = self(ce.IfFalse);

return (t == ce.Test && it == ce.IfTrue && @if == ce.IfFalse) ? expr : Expression.Condition(t, it, @if);

case ExpressionType.MemberAccess:

var ma = (MemberExpression)expr;

var maex = self(ma.Expression);

return (maex == ma.Expression) ? expr : Expression.MakeMemberAccess(maex, ma.Member);

case ExpressionType.Call:

var mce = (MethodCallExpression)expr;

var o = self(mce.Object);

var ca = self.VisitExpressionList(mce.Arguments);

return (o == mce.Object && ca == mce.Arguments) ? expr : Expression.Call(o, mce.Method, ca);

case ExpressionType.Lambda:

var le = (LambdaExpression)expr;

var b = self(le.Body);

return (b == le.Body) ? expr : Expression.Lambda(le.Type, b, le.Parameters);

case ExpressionType.New:

var ne = (NewExpression)expr;

var nar = self.VisitExpressionList(ne.Arguments);

if (nar != ne.Arguments)

return (ne.Members != null) ? Expression.New(ne.Constructor, nar, ne.Members)

: Expression.New(ne.Constructor, nar);

return expr;

case ExpressionType.NewArrayInit:

case ExpressionType.NewArrayBounds:

var na = (NewArrayExpression)expr;

var inits = self.VisitExpressionList(na.Expressions);

if (inits != na.Expressions)

return (na.NodeType == ExpressionType.NewArrayInit) ?

Expression.NewArrayInit(na.Type.GetElementType(), inits) :

Expression.NewArrayBounds(na.Type.GetElementType(), inits);

return expr;

case ExpressionType.Invoke:

var inv = (InvocationExpression)expr;

var args = self.VisitExpressionList(inv.Arguments);

var ie = self(inv.Expression);

return (args == inv.Arguments && ie == inv.Expression) ? expr : Expression.Invoke(ie, args);

case ExpressionType.MemberInit:

var mi = (MemberInitExpression)expr;

var n = (NewExpression)self(mi.NewExpression);

var bindings = self.VisitBindingList(mi.Bindings);

return (n == mi.NewExpression && bindings == mi.Bindings) ? expr : Expression.MemberInit(n, bindings);

case ExpressionType.ListInit:

var li = (ListInitExpression)expr;

var lin = (NewExpression)self(li.NewExpression);

var lii = VisitElementInitializerList(self, li.Initializers);

return (lin == li.NewExpression || lii == li.Initializers) ? expr : Expression.ListInit(lin, lii);

}

if (expr.IsBinary()) {

var b = (BinaryExpression)expr;

var left = self(b.Left);

var right = self(b.Right);

return (left == b.Left && right == b.Right) ? expr : Expression.MakeBinary(expr.NodeType, left, right);

}

else if (expr.IsUnary()) {

var u = (UnaryExpression)expr;

var op = self(u.Operand);

return (u.Operand == op) ? expr : Expression.MakeUnary(u.NodeType, op, expr.Type);

}

return expr;

}

);

public static bool IsBinary(this Expression expr) {

return expr is BinaryExpression;

}

public static bool IsUnary(this Expression expr) {

return expr is UnaryExpression;

}

public static MemberBinding VisitBinding(this Func<Expression, Expression> self, MemberBinding b) {

switch (b.BindingType) {

case MemberBindingType.Assignment:

return self.VisitMemberAssignment((MemberAssignment)b);

case MemberBindingType.MemberBinding: return self.VisitMemberMemberBinding((MemberMemberBinding)b);

}

return self.VisitMemberListBinding((MemberListBinding)b);

}

public static MemberAssignment VisitMemberAssignment(this Func<Expression, Expression> self, MemberAssignment assignment) {

var e = self(assignment.Expression);

return (e == assignment.Expression) ? assignment : Expression.Bind(assignment.Member, e);

}

public static MemberMemberBinding VisitMemberMemberBinding(this Func<Expression, Expression> self, MemberMemberBinding binding) {

var bindings = self.VisitBindingList(binding.Bindings);

return (bindings == binding.Bindings) ? binding : Expression.MemberBind(binding.Member, bindings);

}

public static MemberListBinding VisitMemberListBinding(this Func<Expression, Expression> self, MemberListBinding binding) {

var initializers = self.VisitElementInitializerList(binding.Initializers);

return (initializers == binding.Initializers) ? binding : Expression.ListBind(binding.Member, initializers);

}

public static ElementInit VisitElementInitializer(this Func<Expression, Expression> self, ElementInit initializer) {

var arguments = self.VisitExpressionList(initializer.Arguments);

return (arguments == initializer.Arguments) ? initializer : Expression.ElementInit(initializer.AddMethod, arguments);

}

public static ReadOnlyCollection<Expression> VisitExpressionList(this Func<Expression, Expression> self, ReadOnlyCollection<Expression> original) {

return VisitList(original, e => self(e));

}

public static ReadOnlyCollection<MemberBinding> VisitBindingList(this Func<Expression, Expression> self, ReadOnlyCollection<MemberBinding> original) {

return VisitList(original, e => self.VisitBinding(e));

}

public static ReadOnlyCollection<ElementInit> VisitElementInitializerList(this Func<Expression, Expression> self, ReadOnlyCollection<ElementInit> original) {

return VisitList(original, e => VisitElementInitializer(self, e));

}

private static ReadOnlyCollection<T> VisitList<T>(ReadOnlyCollection<T> original, Func<T, T> op) {

List<T> @new = null;

for (int i = 0, n = original.Count; i < n; i++) {

T init = op(original[i]);

if (@new != null)

@new.Add(init);

else if (!ReferenceEquals(init, original[i])) {

@new = new List<T>(n);

for (int j = 0; j < i; j++)

@new.Add(original[j]);

@new.Add(init);

}

return (@new == null) ? original : @new.AsReadOnly();

}

Once I pasted this in, it looks like a lot of code (~150 lines). But keep in mind that this is complete, reusable mutating visitor for Linq expression trees.

Ok, now to see it in action. This code chains to the visitor above and creates an expression tree rewriter that replaces all adds with subtracts:

var RewriteSubtractToAdd = ExprOp.Visit.Chain(

(self, last, expr) => {

switch (expr.NodeType) {

case ExpressionType.Add:

var b = (BinaryExpression)expr;

return Expression.Subtract(b.Left, b.Right);

default:

return last(expr);

}

);

Here's the how to use the rewriter:

Expression<Func<int, int>> SubtractOneExpr = (n => n - 1);

var AddOneExpr = (LambdaExpression)RewriteSubtractToAdd(SubtractOneExpr);

var AddOne = (Func<int,int>)AddOneExpr.Compile();

Console.WriteLine(AddOne(5));

In this example, I take an expression that subtracts one and rewrite it as an expression that adds one. Then I compile the resulting expression into a delegate and invoke it to prove it work. The chain-of-responsibility expression visitor does the heavy lifting.

(Follow-up 5-25-2007: Aaron's got a different utility class for dealing with Expression trees. Check out ExpressionBuilder: http://blog.magenic.com/blogs/aarone/archive/2007/05/24/Announcing-MetaLinq-_2D00_-Linq-to-Expressions.aspx)

(Follow-up 7-31-2007: Matt Warren (they guy in the office next to mine has posted a different expression visitor. His is pretty close to the one we use internally: http://blogs.msdn.com/mattwar/archive/2007/07/31/linq-building-an-iqueryable-provider-part-ii.aspx)

This posting is provided "AS IS" with no warranties, and confers no rights.

Visitor Revisitted: LINQ, Function Composablity and Chain of Responsibility

Jomo Fisher — Mon, 07 May 2007 22:53:00 GMT

Jomo Fisher—Last time, I wrote about constructing an inline visitor using new C# language features. It worked fine for what it did, but it completely falls down when you want to extend existing visitors that you’ve created. What if I wanted to modify the PrintTree delegate to print negative numbers inside parentheses? There’s not a way to do it. This is a serious limitation, especially when you have hundreds of node types in your tree structure.

In order to fix this problem I went back to first principles. Without worrying about how to implement it, how do I really want functions to compose and recurse in C#? Here’s what I sketched out using the venerable Fibonacci sequence:

var fib = n => n > 1 ? self(n - 1) + self(n - 2) : n

var fib2x = fib chainto n => last(n) * 2;

var fib6x = fib2x chainto n => last(n) * 3;

Here, I’m pretending to add two new keywords to C#—self and last—which are analogous to this and base for classes. Also, I’m pretending to add a third keyword—chainto—which is used for composing functions. The last keyword is only valid on the right side of a chainto and it causes a call to the left side. The call to self always calls the outermost function into which it is composed.

The thing I want is a language encoding of the Chain of Responsibility pattern with a twist. The twist is that the nested responsibility handlers can call the outermost level through self.

Back to Reality

I’m not free to add keywords to C# so I need a way to work with what I have. Here’s a literal transcoding of my idealized functionality into C# 3.0.

var fib = FuncOp.Create<int, int>(

(self, n) => n > 1 ? self(n - 1) + self(n - 2) : n

);

var fib2x = fib.Chain(

(self, last, n) => last(n) * 2

);

var fib6x = fib2x.Chain(

(self, last, n) => last(n) * 3

);

The pretend keywords self and last become lambda expression parameters who’s type is a delegate. The chainto becomes an extension method named Chain.

To my eyes, it’s nicely concise.

Now that I know what I want it to look like, I have to figure out a way to make it work. This turned out to require all kinds of non-obvious plumbing. I think it needs some explaining.

Smuggling Baggage in Static Delegates

First, I want the fib delegate to be directly callable, so the return type from Create(...) needs to be a delegate that takes an int and returns an int. Something like Func<int,int>.

So that means that the Chain method needs to operate on Func<int,int>. At this point, I’m already in trouble. The reason is that I need to repoint fib’s calls to self(...) to call the result of the call to Chain. The problem is that I have a Func<int, int> and what I want is the original Func<Func<int,int>, int, int> that was originally passed in to Chain. I need to smuggle the ‘unbound’ version of fib around with the regular fib but hide it from the user.

The trick is to realize that fib is a static delegate. So this means that its Delegate.Target member is always null. Since its not being used for its intended purpose (to hold the delegate’s calling target for non-static calls) I’ll use it for my own purposes. To see what I mean, here’s an example of smuggling a random string around with a static delegate:

var addOne = new Func<int, int>(

new Smuggler("My totally random string.", n => n + 1).Invoke);

Console.WriteLine(addOne(5));

Console.WriteLine(((Smuggler)addOne.Target).MyString);

class Smuggler {

private Func<int, int> f;

public string MyString { get; private set; }

public Smuggler(String myString, Func<int, int> f) {

this.f = f;

this.MyString = myString;

}

public int Invoke(int n) { return f(n); }

}

Using this trick, I smuggle around the unbound version of the delegate along with a pointer to the prior function (thus forming a linked list of delegates that have been composed).

Simulated ref Lambda Expression

Each call to Chain needs to repoint all calls to ‘self’ for all prior functions in the chain. In order to do this, I needed to curry a lambda expression against a ref to delegate:

void Function(ref Func<int,int> self) {

Func<int, int> f = (n) => self(n);

}

Unfortunately for me, the C# language doesn’t allow ref parameters inside delegates. I’m not sure why, there’s no obvious technical reason.

This problem can be solved by making a RefOf class to hold the delegate.

private class RefOf<T> {

public T Ref { get; set; }

}

void Function(RefOf<Func<int, int>> self) {

Func<int, int> f = (n) => self.Ref(n);

}

Putting it all Together

Now that we have the tools, let’s put it all together:

static class FuncOp {

private class Binding<T, TResult> {

public Func<T, TResult> Bound { get; private set; }

public Func<Func<T, TResult>,

Func<T, TResult>, T, TResult> Unbound { get; private set; }

public Binding<T, TResult> LastBinding { get; private set; }

public Binding(Func<T, TResult> bound,

Func<Func<T, TResult>,

Func<T, TResult>, T, TResult> unbound,

Binding<T, TResult> lastBinding) {

Bound = bound;

Unbound = unbound;

LastBinding = lastBinding;

}

public TResult Invoke(T t) { return Bound(t); }

}

private class RefOf<T> {

public T Ref { get; set; }

}

public static Func<T, TResult> Create<T, TResult>(

Func<Func<T, TResult>, T, TResult> function) {

var selfRef = new RefOf<Func<T,TResult>>();

var unbound = new Func<Func<T, TResult>,

Func<T, TResult>, T, TResult>(

(s, l, t) => function(s, t)

);

selfRef.Ref = Chain(selfRef, unbound, null);

return selfRef.Ref;

}

private static Func<T, TResult> Chain<T, TResult>(

RefOf<Func<T, TResult>> selfRef,

Func<Func<T, TResult>,

Func<T, TResult>, T, TResult> unbound,

Binding<T, TResult> lastBinding) {

Func<T, TResult> last = null;

Func<T, TResult> bound = (t) => unbound(selfRef.Ref, last, t);

if (lastBinding != null)

last = Chain(selfRef, lastBinding.Unbound,

lastBinding.LastBinding);

var binding = new Binding<T, TResult>(bound, unbound,

lastBinding);

return new Func<T, TResult>(binding.Invoke);

}

public static Func<T, TResult> Chain<T, TResult>(

this Func<T, TResult> lastFunction,

Func<Func<T, TResult>,

Func<T, TResult>, T, TResult> selfFunction) {

var selfRef = new RefOf<Func<T, TResult>>();

var lastBinding = (Binding<T, TResult>)lastFunction.Target;

selfRef.Ref = Chain<T, TResult>(selfRef, selfFunction,

lastBinding);

return selfRef.Ref;

}

Composing Functions in Action

Ok, now I want to see how well this solves my original problem: reusing the PrintTree delegate while putting negative numbers in parenthesis. Here’s the original PrintTree transcoded into the new form:

Node addNumbers = Node.Add(

Node.Add(Node.Constant(-1), Node.Constant(-2)),

Node.Add(Node.Constant(3), Node.Constant(5)));

var UnhandledNode = FuncOp.Create<Node, Node>(

(self, n) => { throw new Exception("Unhandled node type "

+ n.NodeType); }

var PrintTree = UnhandledNode.Chain(

(self, last, n) => {

switch (n.NodeType) {

case NodeType.Add:

BinaryNode bn = (BinaryNode)n;

self(bn.Left);

Console.Write("+");

self(bn.Right);

return n;

case NodeType.Constant:

ConstantNode cn = (ConstantNode)n;

Console.Write(cn.Value);

return n;

default:

return last(n);

}

);

PrintTree(addNumbers);

I like this a lot better than the prior solution. Aside from being composable, I also get to use the plain old C# switch\case instead of inventing my own parallel mechanism. Also, the code pretty much looks like what it does.

Here’s the code that will extend PrintTree to parenthesize negative numbers:

var PrintParens = PrintTree.Chain(

(self, last, n) => {

switch (n.NodeType) {

case NodeType.Constant:

ConstantNode cn = (ConstantNode)n;

if (cn.Value is int) {

int v = (int)cn.Value;

if (v < 0) Console.Write("(" + v + ")");

else Console.Write(v);

} else {

Console.Write(cn.Value);

}

return n;

default:

return last(n);

}

);

PrintParens(addNumbers);

As expected, there’s no need to handle NodeType.Add at this level.

It's interesting to me that turning a Visitor inside-out gives you a Chain of Responsibility. I wonder if there are other OO<-->Functional design pattern dualities like this.

This posting is provided "AS IS" with no warranties, and confers no rights.

(Note 5-24-2007: I put this pattern to good use here: http://blogs.msdn.com/jomo_fisher/archive/2007/05/23/dealing-with-linq-s-immutable-expression-trees.aspx)

Inline Visitor Construction using LINQ

Jomo Fisher — Sat, 05 May 2007 00:03:00 GMT

Jomo Fisher—My current job is in the C# team working on LINQ to SQL. Because of nature of programming languages, very few days go by that I don’t deal with syntax trees and the visitor pattern. Occasionally, it would be convenient to create a quick one-off visitor for doing a manipulation on a tree. It would be nice to create a simple in-place visitor—say in a delegate--without going through the trouble of creating an internally-visible class.

One of the problems you run into right away is that the visitor pattern requires recursion and it’s not apparent how to create recursive delegates. Fortunately, smart people have figured this out already and we can just make use of the fruits of their labor: See this for example.

After some additional head-scratching, I managed to come up with a system for creating in-place visitors. Here’s an example of an inline visitor that just prints the contents of a node tree that I defined:

Node addTwo = Node.Add(Node.Constant(1), Node.Constant(2));

var PrintTree = Visitor.Create<Node>(visit => node =>

Visitor.Case(node == null, () => node,

() => Visitor.Case(node.NodeType == NodeType.Add, () => {

BinaryNode b = (BinaryNode)node;

visit(b.Left);

Console.Write(" + ");

visit(b.Right);

return node;

() => Visitor.Case(node.NodeType == NodeType.Constant, () => {

ConstantNode cn = (ConstantNode)node;

Console.Write(cn.Value);

return node;

}

)))

);

PrintTree(addTwo);

It’s not exactly the prettiest thing you can imagine, but it does do the job. It works by chaining Visitor.Case calls together, each with a delegate block to execute if there’s a match. Notice the call to visit in the 'Add' case--that's the recursion I was talking about. Here’s the supporting code that makes it work:

static class Visitor {

public static T Case<T>(bool match,

Func<T> matched, Func<T> notMatched) {

return match ? matched() : notMatched();

}

public static T Case<T>(bool match, Func<T> matched) {

if (match) {

return matched();

}

throw new Exception("Unhandled case");

}

private delegate Func<A, R> Recursive<A, R>(Recursive<A, R> r);

public static Func<TNode, TNode> Create<TNode>(

Func<Func<TNode, TNode>, Func<TNode, TNode>> f) {

Recursive<TNode, TNode> rec = r => a => f(r(r))(a);

return rec(rec);

}

And for completeness, here’s the example Node tree that I used:

enum NodeType {

Add,

Constant

}

abstract class Node {

public Node(NodeType type) { NodeType = type; }

public NodeType NodeType { get; private set; }

public static BinaryNode Add(Node left, Node right) {

return new BinaryNode(left, right, NodeType.Add);

}

public static ConstantNode Constant(object value) {

return new ConstantNode(value);

}

sealed class BinaryNode : Node {

public BinaryNode(Node left, Node right, NodeType type)

: base(type) {

Left = left;

Right = right;

}

public Node Left { get; private set; }

public Node Right { get; private set; }

}

sealed class ConstantNode : Node {

public ConstantNode(object value)

: base(NodeType.Constant) {

Value = value;

}

public object Value { get; private set; }

}

I don’t see a direct way to make the calling pattern simpler. Maybe one of you will have an idea for improving it. I do think there may be an indirect way to make it better: represent the whole visitor as an Expression tree that is rewritten (using...a visitor) and then using Expression.Compile. I think I may try that next.

(Update 5/7/2007--I found a better way to solve this whole problem class. See http://blogs.msdn.com/jomo_fisher/archive/2007/05/07/visitor-revisitted-linq-function-composablity-and-chain-of-responsibility.aspx)

This posting is provided "AS IS" with no warranties, and confers no rights.

Fast Switching with LINQ

Jomo Fisher — Wed, 28 Mar 2007 22:37:00 GMT

Jomo Fisher—I’ve run into a performance problem several times in my career that I’ve never found a truly satisfying answer for until now. The problem can be distilled down to this:

Look up a value based on a string key. The set of strings is fixed and no unknown key values can occur.

Consider my personal rankings of the Seven Dwarves on a scale of 1-10:

happy=9, sneezy=2, doc=7, sleepy=8, dopey=9, grumpy=2, bashful=6

I need a function that takes a name and returns a ranking. The default solution for this problem should be to use a Dictionary or HashTable. The implementations that ship with the .NET framework are extremely fast.

However, these container classes offer more features than I need for this problem. New keys can be added but my set is fixed. They can tell you whether a key is valid or not but I know a priori that the keys are limited to a fixed set. They can enumerate the set of keys or the set of values but I don’t need this capability.

Any time I see a data structure with a capability I’m not using it makes me wonder whether I can trade that capability for something I do need—in this case a speed boost.

If I was really desperate for a performance gain then it was possible to write a function like:

static int Lookup(string s) {

if (s.Length < 6) {

if (s.Length < 5) return 7;

else return 9;

} else {

if (s[0] < 's') {

if (s[0] < 'g') return 6;

else return 2;

} else {

if (s[1] < 'n') return 8;

else return 2;

}

Notice that we only have to look at the length and the first two characters of the string to make the decision. This function is fast but nearly impossible to maintain or debug. Also, I have to know the set of strings at compile time. All of these drawbacks make this approach significantly less useful.

Enter the LINQ Expression Compiler that will be available in the .NET 3.5. With the new expression support it’s possible to write an expression at runtime and then compile this expression into straight IL (which will be jitted into machine code). It turned out to be pretty easy to write a switch compiler that would generate an appropriate lookup expression on the fly. I wrote a class called SwitchCompiler to do the heavy lifting. Here’s how it’s called:

var dict = new Dictionary<string, int> {

{"happy", 9}, {"sneezy", 2},

{"doc", 7}, {"sleepy", 8},

{"dopey", 9}, {"grumpy", 2},

{"bashful", 6}

};

var Lookup = SwitchCompiler.CreateSwitch(dict);

var v = Lookup("doc");

Debug.Assert(v == 7);

SwitchCompiler first builds up an expression that looks like this:

s.Length < 6 ? (s.Length < 5 ? 7 : 9) :

(s[0] < 's' ? (s[0] < 'g' ? 6 : 2) : (s[1] < 'n' ? 8 : 2));

And then compiles this into a delegate returned into Lookup. (It should also be possible to generate a perfect minimal hash in the Compile method. I haven't tried this).

The actual implementation of SwitchCompiler is about 65 lines of code. You can see it in the attachment.

On my machine, looking up each value in a tight loop 1 million times takes 70ms while the corresponding loop using Dictionary takes 697ms. That’s close to a 900% performance improvement.

This posting is provided "AS IS" with no warranties, and confers no rights.

C# 3.0 Expression Trees

Jomo Fisher — Fri, 07 Oct 2005 23:18:00 GMT

IanG gives a brilliant explanation of C# 3.0 expression trees and how they enable efficient queries in DLinq: http://www.interact-sw.co.uk/iangblog/2005/09/30/expressiontrees

This posting is provided "AS IS" with no warranties, and confers no rights.

Creating Custom Aggregate Functions in LINQ

Jomo Fisher — Thu, 15 Sep 2005 21:57:00 GMT

Jomo Fisher—Adriane asks whether it’s possible to create your own aggregate function like Sum, Avg, Count, etc. For object queries, the answer is yes. First, let’s look at the actual implementation of Sum:

public static int Sum(this IEnumerable<int> source) {

int sum = 0;

foreach (int v in source) sum += v;

return sum;

}

You can see this yourself if you have the LINQ Preview for C# installed. This is a straightforward function except for the ‘this’ on the first parameter. This makes Sum an extension method. I talk about this in more detail here.

So let’s write our own method and call it.

using System;

using System.Collections.Generic;

static class Program {

public static int SumSquares(this IEnumerable<int> source) {

int sum = 0;

foreach (int v in source) sum += (v*v);

return sum;

}

static void Main(string[] args) {

int [] i = new int [] {1,2,3};

Console.WriteLine(i.SumSquares());

}

For DLinq, there’s no way to do this today.

This posting is provided "AS IS" with no warranties, and confers no rights.

Evolution of a C# Query—Step by step from C# 1.1 to LINQ

Jomo Fisher — Tue, 13 Sep 2005 20:46:00 GMT

Jomo Fisher—The future of C# was recently unveiled at PDC. Object, XML and relational data will be integrated deeply into the language. This isn’t really a new direction for C#, it’s the next step down a path that C# has always been headed. To see this, let’s look at a simple task—filtering a set of objects—and see how C# language features have made it easier and more natural over time.

Queries in the C# 1.1 Era

We have an Employee class:

class Employee {

public string Name;

public int Years;

public string Department;

}

We want to give everyone with at least four years service a gold watch. Here’s how we might get this set in C# 1.1:

static Employee[] GoldWatch(Employee[] employees) {

int resultCount = 0;

for (int i = 0; i < employees.Length; ++i) {

if (employees[i].Years > 3) {

++resultCount;

}

Employee[] results = new Employee[resultCount];

for (int i = 0, j = 0; i < employees.Length; ++i) {

if (employees[i].Years > 3) {

results[j] = employees[i];

++j;

}

return results;

}

This method counts the eligible employees, allocates an array, and fills the array with matches. This works, but you’ve probably identified several problems with it: The employees array is iterated twice, the business rule ‘Years>3’ is written twice, and generally this is more complex than we would expect for such a simple task.

Here’s one possible simplification (still in C# 1.1):

static Employee[] GoldWatch(Employee[] employees) {

ArrayList results = new ArrayList();

for (int i = 0; i < employees.Length; ++i) {

if (employees[i].Years > 3) {

results.Add(employees[i]);

}

return (Employee[])results.ToArray(typeof(Employee));

}

We’ve gotten it down to just one pass, but we had to give up some type safety because ArrayList holds ‘object’. One consequence is the complicated cast at the end.

Both of the approaches above also have a flexibility problem: They require employees to be given as an array. We could write a similar method that takes ArrayList as a parameter but there are other collection types we may want to support too.

Here’s another approach:

static Employee[] GoldWatch(IEnumerable employees) {

ArrayList results = new ArrayList();

foreach(Employee employee in employees) {

if (employee.Years > 3) {

results.Add(employee);

}

return (Employee[])results.ToArray(typeof(Employee));

}

This works with arrays of Employee and other collections like ArrayList. We give up some more type safety, however, because the compiler can’t figure out whether the employees IEnumerable truly contains only Employee instances.

We’ve done about as much as we can with C# 1.1.

Queries in the C# 2.0 Era

C# 2.0 brings some new tools that we can use to make our query better. First, let’s attack the type safety problem:

static Employee[]

GoldWatch(IEnumerable<Employee> employees) {

List<Employee> results = new List<Employee>();

foreach (Employee employee in employees) {

if (employee.Years > 3) {

results.Add(employee);

}

return results.ToArray();

}

Generics allow complete type safety while keeping a simple implementation.

We still have a potential performance problem, however: We’re building up the entire list before returning. What if the result set is very large? What if the caller only needs to look at the first few items?

If we may have these calling patterns and we can tolerate returning an IEnumerable<Employee> rather than an array then there is a better solution using iterators (another feature new for C# 2.0).

static IEnumerable<Employee>

GoldWatch(IEnumerable<Employee> employees) {

foreach (Employee employee in employees) {

if (employee.Years > 3) {

yield return employee;

}

Now there’s no temporary copy of employees and the caller gets to decide how many elements it wants. If the caller asks for just the first element then only the work to return one element is done.

This code is simple and will be maintainable because the code looks like what it does.

Yeah!

But what happens when we need to do a similar query? Say that we later discover that we need to return a list of people in the Sales department. We could code up a new SalesForce() method that looks the same except that it has a different filtering condition. In this case, the two methods look similar enough that we want to try to see if we can factor the code better.

We might try using delegates to write a generic ‘Filter’ method:

delegate bool Choose(Employee employee);

static IEnumerable<Employee>

Filter(IEnumerable<Employee> employees, Choose choose) {

foreach (Employee employee in employees) {

if (choose(employee)) {

yield return employee;

}

static bool GoldWatchChoose(Employee employee) {

return employee.Years>3;

}

static bool SalesForceChoose(Employee employee) {

return employee.Department=="Sales";

}

static IEnumerable<Employee>

GoldWatch(IEnumerable<Employee> s) {

return Filter(employees, new Choose(GoldWatchChoose));

}

static IEnumerable<Employee>

SalesForce(IEnumerable<Employee> s) {

return Filter(employees, new Choose(SalesForceChoose));

}

In this case, every time we have a new type of query we have to add two new methods: the query method and a delegate method used to choose which employees to return. This proliferation of methods is a maintainability problem.

We could use anonymous delegates—a C# 2.0 feature:

static IEnumerable<Employee>

GoldWatch(IEnumerable<Employee> s) {

return Filter(employees,

delegate(Employee employee) {

return employee.Years>3;

}

);

}

static IEnumerable<Employee>

SalesForce(IEnumerable<Employee> s) {

return Filter(employees,

delegate(Employee employee) {

return employee.Department=="Sales";

}

);

}

Now we only need to add one new method for every new query type. Also, we have the option of calling Filter() directly. In this case, we wouldn’t need to add any new methods. On the downside, seeing a tiny method implementation passed as a parameter to another method is jarring and perhaps reduces the readability of the code.

We’ve done about as much as we can with C# 2.0.

Queries in the C# 3.0 Era

With C# 3.0 we’ll have tools to make our query better.

Those anonymous delegates are good, but we’d like something a little simpler and more maintainable. C# 3.0 has the concept of a lambda expression. For our purposes, you can think of a lambda expression as a shortcut for an anonymous delegate. Here are the queries rewritten to use lambda expressions.

static IEnumerable<Employee>

GoldWatch(IEnumerable<Employee> employees) {

return Filter(employees,

employee => employee.Years>3

);

}

static IEnumerable<Employee>

SalesForce(IEnumerable<Employee> employees) {

return Filter(employees,

employee => employee.Department=="Sales"

);

}

This is simple and will be maintainable. We still have a few issues, however. You can see one problem when you look at how our queries will be called:

GoldWatch(employees);

SalesForce(employees);

Coming from an OO world, we’re used to seeing using a noun.Verb() calling pattern. Ideally, we want to ask a set of employees for its sales force. Something like:

employees.GoldWatch();

employees.SalesForce();

We might try to define a new class called Employees which inherits from IEnumerable<Employee>. The problem here, though, is that we know our callers want to use other implementations of IEnumerable<Employee> such as Employee[] and List<Employee>.

C# 3.0 addresses this issue with extension methods. Here’s what it would like like:

static IEnumerable<Employee>

Filter(this IEnumerable<Employee> employees, Choose choose) {

foreach (Employee employee in employees) {

if (choose(employee)) {

yield return employee;

}

static IEnumerable<Employee>

GoldWatch(this IEnumerable<Employee> employees) {

return employees.Filter(employee => employee.Years>3);

}

static IEnumerable<Employee>

SalesForce(this IEnumerable<Employee> employees) {

return employees.Filter(

employee => employee.Department=="Sales");

}

Notice the addition of the this keyword in front of the first parameter of each method. Now we can call these methods as if they were members of the IEnumerable<Employee> class.

employees.GoldWatch();

employees.SalesForce();

employees.Filter(employee => employee.Department=="Sales");

Notice this lets the caller compose more complex queries by chaining:

employees

.GoldWatch()

.SalesForce();

Here we get members of the sales force which should receive a gold watch.

This looks pretty good, but what happens when we have to start filtering our Customers and our Inventory lists the same way we’ve been filtering our Employee lists?

Instead of creating a new Filter implementation for every possible type, we can make the Filter method generic:

delegate bool Choose<T>(T t);

static IEnumerable<T>

Filter<T>(this IEnumerable<T> items, Choose<T> choose) {

foreach (T item in items) {

if (choose(item)) {

yield return item;

}

Now we can filter any type of collection we like.

int [] a = new int [] {1,2,3,4,5};

a.Filter(i => i==1 || i==3);

The Filter method is so useful and so general purpose that there will be a built-in implementation of it called Where. Here’s the actual implementation of Where for the code we delivered at PDC:

public delegate T Func<A0, T>(A0 arg0);

public static

IEnumerable<T> Where<T>(this IEnumerable<T> source,

Func<T, bool> predicate) {

foreach (T element in source) {

if (predicate(element)) yield return element;

}

If you have installed the ‘LINQ Preview’, you can see the Where method and a bunch of others by opening ‘C:\Program Files\LINQ Preview\docs\Sequence.cs’

Next, we'll take this query into SQL Server and see how DLinq helps unify the worlds of objects and relational data.

This posting is provided "AS IS" with no warranties, and confers no rights.