I just found this one in a custom Linq provider for .net:
//select is a royal pain in the ass where
//the parameter passed to CreateQuery isn't actually the one that goes in the call
//requiring this workaround. Not sure how straight Linq to Objects does it.
And this one
//expressions have to be compiled in order to work with the method call on
//straight Enumerable somehow, LINQ to objects itself magically does this.
//Reflector shows a mess, so I (Aaron) invented my own way. God love unit tests!
And i just found this one as well... it just gets better
//ok, this is a hairy, dirty, and nasty piece of code
//the alternatives are substantially worse than this though
//i.e. when you do your own provider, LINQ assumes that
//you are going to implement your own expression tree visitor and
//do it all yourself. Frankly, I still have xmas shopping to do
//and I really don't want us to be foobared when we get
//even more extension methods added to LINQ
//therefore, we are pulling execute based on taking the calling the
//standard execute on enumerable, but using our own class
//
//optimization can occur from here on an as needed basis, that is
//check for the value of mex.Method.Name, and write a handler for
//that method
//
//also, it may not be a bad idea to rather than do this reflection
//each and every time somehow cache the reflected methodinfos and do
//lookups that way that said, we need a complete red/green/refactor
//cycle here before I am touching that one
And this one
//Compile that mutherf-ker, invoke it, and get the resulting hash