[DrJokepu]

You (and the writer of the article), of course, mean Linq to Objects. Linq providers are free to compile Linq structures to whatever they want to, in the case of objects that means compiling to list comprehensions, but for example in the case of Linq to SQL it all compiles down to SQL queries.

(Sorry for nipticking, the reason I'm pointing this out because people get confused about the unfortunate Linq terminology all the time).

[kodefuguru]

IQueryable's get converted to expression trees which then get converted to sql. It's more of a "translated" to sql rather than a "compiled" to sql. The power of IQueryable is that the expression trees can be converted to so many different kinds of expressions, and you can write your own.

IEnumerable's extensions are mostly iterators over sequences.

[btilly]

IQueryable's get converted to expression trees which then get converted to sql. It's more of a "translated" to sql rather than a "compiled" to sql.

You've just described how compilers work, minus optional attempts at optimization and optional excess passes. Most of which take place either after the expression tree has been generated, or somewhere during the conversion process. Therefore I'd call what you've described "compilation".

[crc32]

Compilation is translation.

[logicalmind]

I find it somewhat ironic that you try to specify that the term LINQ be limited to LINQ to Objects and then proceed to explain how it doesn't matter whether the provider is for objects or SQL. Granted, his examples are all LINQ to Objects, but I see no need to be that specific. The provider could be Objects, SQL, Parallel Objects, etc. But the LINQ is still the same.

[DrJokepu]

Let me clarify what I meant. Linq to SQL is compiled to SQL queries. SQL queries are not list comprehension, not even on server side (apart from trivial cases). I wasn't trying to suggest that the term "Linq" is limited to Linq to Objects, I was trying to say exactly the opposite.

[logicalmind]

I'm not following why you are trying to specify the providers implementation of the list comprehension when it doesn't matter to the LINQ query you write. LINQ is working on lists and provides standard query operators. When you write a LINQ query it's turned into an expression tree. Based on the provider of the original list the query is turned into an actual implementation of your LINQ query. Whether this is ultimately translated to a SQL query, an LDAP query, assembly instructions, etc. is of little concern to the writer of the LINQ query. Of course, there are some instances where you do care if performance is of importance.

I believe that the point of author was that any time you are iterating over a list, you should really think about whether you can replace the iteration with a LINQ query. It really doesn't matter whether the list being iterated is an underlying list of objects, a table in an RDBMS, etc.

[nlawalker]

> When you write a LINQ query it's turned into an expression tree.

I believe that this is not the case if you are using LINQ to Objects unless you stick an explicit cast in there somewhere, but I could be wrong. I think that if you simply use the LINQ extension methods on an in-memory IEnumerable, they are simple method calls and involve no compilation to an expression tree.