Why to use lambda expression when we have LINQ queries just to shorten the length of code , increase the speed of development or is there any other reason which can only be achieved by Lambda expression & not by LINQ queries.
Query expressions only cover a small subset of the LINQ operators, and are only applicable when you have the actual expression involved to hand, rather than (say) having a Func<T, bool> to act as the predicate, in which case things become ugly. So instead of writing:
Func<Foo, bool> predicate = ...; // Get predicate from somewhere
var query = from x in collection
where predicate(x)
select x;
I'd much rather write:
Func<Foo, bool> predicate = ...; // Get predicate from somewhere
var query = collection.Where(predicate);
There are various other cases where using non-query expression syntax is simpler, particularly if your query only uses a single operator.
Query expressions are effectively translated into non-query expressions, so anything you can do in query expressions can be expressed in non-query expressions. Use query expressions where they make the code simpler and more readable; don't use them where they don't.
I have more information about how query expressions work in a blog post that you may be interested in.
any other reason which can only be achieved by Lambda expression & not by LINQ queries.
There are some LINQ extension methods which do not have counterparts in LINQ query expressions, and will require the use of Lambda Expressions. A good example is Enumerable.ToLookup - if you want to create an ILookup, you need to use lambdas to generate this.
Related
in linq, .Where takes a Expression> predicate, which I can write in F# as
<# fun item:'a -> condition #> // Expr<'a -> bool>
I'm using FSharp.Powerpack to build the expression from a quotation, but what it gives me is a MethodCallExpression. Looking deep, the powerpack code builds the lambda correctly, but wraps it in a Convert call (why is that?). I wonder if casting the argument to the method call (a lambda) would finally give me the Expression> I need.
So the question is why the Convert call, and how to actually get the lambda with the Func signature.
I can't remember off the top of my head where I found this bit of code, but this is what I use to convert an Expr<'a -> 'b> to Expression<Func<'a, 'b>>. Hopefully this will solve your problem.
open System
open System.Linq.Expressions
open Microsoft.FSharp.Quotations
open Microsoft.FSharp.Linq.QuotationEvaluation
let toLinq (expr : Expr<'a -> 'b>) =
let linq = expr.ToLinqExpression()
let call = linq :?> MethodCallExpression
let lambda = call.Arguments.[0] :?> LambdaExpression
Expression.Lambda<Func<'a, 'b>>(lambda.Body, lambda.Parameters)
One way you can now do this is to take advantage of the fact that F# will perform this conversion automatically when invoking methods on .NET types that expect a Expression<Func<...>>.
I'm not entirely sure when this got added to the language, but certainly with F# 4, you don't need to explicitly convert F# expressions into LINQ ones. If the reason you wanted to do this in the first place was to be able to use IQueryable LINQ APIs (or other expression-based .NET APIs) then it now just works with no effort, e.g.:
someEfDataContext.MyEntities.Single(fun e -> e.Id = 42)
just works. Even though this looks like an ordinary lambda (we've not used F#'s expression syntax), this compiles to code that produces an F# expression object, and then passes that to LeafExpressionConverter.QuotationToExpression to turn it into a LINQ expression object.
But sometimes you'll want to get hold of the LINQ-style expression object directly in F#. (E.g., sometimes it's useful to write an F# function that produces an expression that you'll use in multiple queries.) In that case you can write a helper like this:
type FunAs() =
static member LinqExpression<'T, 'TResult>(e: Expression<Func<'T, 'TResult>>) = e
This looks like it does nothing - it just returns its argument. However, because FunAs is a .NET type, F# will automatically compile any call site that invokes this with a fun expression into code that generates a suitable LINQ query expression. E.g.:
let linqExpr = FunAs.LinqExpression(fun (e:MyEntity) -> e.Id = 42)
Here, linqExpr will be of type Expression<Func<MyEntity, bool>>.
The key to this is that this method is a member of a .NET Type. If you try the exact same thing with an ordinary F# function:
let funAsLinqExpression<'T, 'TResult>(e: Expression<Func<'T, 'TResult>>) = e
which seems like it should mean exactly the same thing as FunAs.LinqExpression, you'll find that you can't call it in the same way. E.g., if you try this:
let linqExpr = funAsLinqExpression(fun (e:MyEntity) -> e.Id = 42)
You'll get a (slightly unhelpful) error: 'This function takes too many arguments, or is used in a context where a function is not expected`.
By making this function a member of a .NET type, we can take advantage of F#'s helpful "You seem to be invoking a .NET API that expects a LINQ-style expression, let me take care of that for you" feature.
(It's possible that there's some more explicit way of asking the LINQ compiler to perform this same trick for you without bringing a .NET type into the picture, but I've not found it.)
What are the pros and cons of LINQ operators and LINQ methods? Does one have limitations or added capabilities the other does not?
The term "operator" in LINQ isn't the same as "operator" in the normal sense of C# language operators, (+, && etc). The LINQ standard query operators are just the LINQ methods which are expected to be available where possible through most providers (and the ones made available through LINQ to Objects in particular).
Were you actually asking about the pros and cons of using query expressions like this:
var query = from item in source
where item.SomeProperty == 5
select item.OtherProperty;
vs the "fluent interface" or "dot notation" of normal extension method calls:
var query = source.Where(item => item.SomeProperty == 5)
.Select(item => item.OtherProperty);
? If so, I can write about that in more detail, but basically:
There'll generally be no performance difference, as query expressions are effectively translated by the compiler into the latter syntax. Occasionally there are overloads you can use from dot notation which aren't available via query expressions, and you may be able to make things more efficient that way.
Operators which use multiple delegates (e.g. Join, GroupBy) tend to be more readable in query expression syntax
If your query would use lots of transparent identifiers in query expression syntax, the dot notation is likely to be ugly
If your query is very simple (just a Where and/or Select) then dot notation is likely to be simpler
If you're using methods which are unsupported by query expressions (e.g. Count(), ToList() etc) then having to bracket the query expression can be ugly
I love using LINQ in .NET, but I want to know how that works internally?
It makes more sense to ask about a particular aspect of LINQ. It's a bit like asking "How Windows works" otherwise.
The key parts of LINQ are for me, from a C# perspective:
Expression trees. These are representations of code as data. For instance, an expression tree could represent the notion of "take a string parameter, call the Length property on it, and return the result". The fact that these exist as data rather than as compiled code means that LINQ providers such as LINQ to SQL can analyze them and convert them into SQL.
Lambda expressions. These are expressions like this:
x => x * 2
(int x, int y) => x * y
() => { Console.WriteLine("Block"); Console.WriteLine("Lambda"); }
Lambda expressions are converted either into delegates or expression trees.
Anonymous types. These are expressions like this:
new { X=10, Y=20 }
These are still statically typed, it's just the compiler generates an immutable type for you with properties X and Y. These are usually used with var which allows the type of a local variable to be inferred from its initialization expression.
Query expressions. These are expressions like this:
from person in people
where person.Age < 18
select person.Name
These are translated by the C# compiler into "normal" C# 3.0 (i.e. a form which doesn't use query expressions). Overload resolution etc is applied afterwards, which is absolutely key to being able to use the same query syntax with multiple data types, without the compiler having any knowledge of types such as Queryable. The above expression would be translated into:
people.Where(person => person.Age < 18)
.Select(person => person.Name)
Extension methods. These are static methods which can be used as if they were instance methods of the type of the first parameter. For example, an extension method like this:
public static int CountAsciiDigits(this string text)
{
return text.Count(letter => letter >= '0' && letter <= '9');
}
can then be used like this:
string foo = "123abc456";
int count = foo.CountAsciiDigits();
Note that the implementation of CountAsciiDigits uses another extension method, Enumerable.Count().
That's most of the relevant language aspects. Then there are the implementations of the standard query operators, in LINQ providers such as LINQ to Objects and LINQ to SQL etc. I have a presentation about how it's reasonably simple to implement LINQ to Objects - it's on the "Talks" page of the C# in Depth web site.
The way providers such as LINQ to SQL work is generally via the Queryable class. At their core, they translate expression trees into other query formats, and then construct appropriate objects with the results of executing those out-of-process queries.
Does that cover everything you were interested in? If there's anything in particular you still want to know about, just edit your question and I'll have a go.
LINQ is basically a combination of C# 3.0 discrete features of these:
local variable type inference
auto properties (not implemented in VB 9.0)
extension methods
lambda expressions
anonymous type initializers
query comprehension
For more information about the journey to get there (LINQ), see this video of Anders in LANGNET 2008:
http://download.microsoft.com/download/c/e/5/ce5434ca-4f54-42b1-81ea-7f5a72f3b1dd/1-01%20-%20CSharp3%20-%20Anders%20Hejlsberg.wmv
In simple a form, the compiler takes your code-query and converts it into a bunch of generic classes and calls. Underneath, in case of Linq2Sql, a dynamic SQL query gets constructed and executed using DbCommand, DbDataReader etc.
Say you have:
var q = from x in dc.mytable select x;
it gets converted into following code:
IQueryable<tbl_dir_office> q =
dc.mytable.Select<tbl_dir_office, tbl_dir_office>(
Expression.Lambda<Func<mytable, mytable>>(
exp = Expression.Parameter(typeof(mytable), "x"),
new ParameterExpression[] { exp }
)
);
Lots of generics, huge overhead.
Basically linq is a mixture of some language facilities (compiler) and some framework extensions. So when you write linq queries, they get executed using appropriate interfaces such as IQuerable. Also note that the runtime has no role in linq.
But it is difficult to do justice to linq in a short answer. I recommend you read some book to get yourself in it. I am not sure about the book that tells you internals of Linq but Linq in Action gives a good handson about it.
For example:
m_lottTorqueTools = (From t In m_lottTorqueTools _
Where Not t.SlotNumber = toolTuple.SlotNumber _
And Not t.StationIndex = toolTuple.StationIndex).ToList
What algorithm occurs here? Is there a nested for loop going on in the background? Does it construct a hash table for these fields? I'm curious.
Query expressions are translated into extension method calls, usually. (They don't have to be, but 99.9% of queries use IEnumerable<T> or IQueryable<T>.)
The exact algorithm of what that method does varies from method to method. Your sample query wouldn't use any hash tables, but joins or grouping operations do, for example.
The simple Where call translates to something like this in C# (using iterator blocks, which aren't available in VB at the moment as far as I'm aware):
public static IEnumerable<T> Where(this IEnumerable<T> source,
Func<T, bool> predicate)
{
// Argument checking omitted
foreach (T element in source)
{
if (predicate(element))
{
yield return element;
}
}
}
The predicate is provided as a delegate (or an expression tree if you're using IQueryable<T>) and is called on each item in the sequence. The results are streamed and execution is deferred - in other words, nothing happens until you start asking for items from the result, and even then it only does as much as it needs to in order to provide the next result. Some operators aren't deferred (basically the ones which return a single value instead of a sequence) and some buffer the input (e.g. Reverse has to read to the end of the sequence before it can return any results, because the last result it reads is the first one it has to yield).
It's beyond the scope of a single answer to give details of every single LINQ operator I'm afraid, but if you have questions about specific ones I'm sure we can oblige.
I should add that if you're using LINQ to SQL or another provider that's based on IQueryable<T>, things are rather different. The Queryable class builds up the query (with the help of the provider, which implements IQueryable<T> to start with) and then the query is generally translated into a more appropriate form (e.g. SQL) by the provider. The exact details (including buffering, streaming etc) will entirely depend on the provider.
LINQ in general has a lot going on behind the scenes. With any query, it is first translated into an expression tree using an IQueryableProvider and from there the query is typically compiled into CIL code and a delegate is generated pointing to this function, which you are essentially using whenever you call the query. That's an extremely simplified overview - if you want to read a great article on the subject, I recommend you look at How LINQ Works - Creating Queries. Jon Skeet also posted a good answer on this site to this question.
What happens not only depends on the methods, but also depends on the LINQ provider in use. In the case where an IQueryable<T> is being returned, it is the LINQ provider that interprets the expression tree and processes it however it likes.
I have the following sample XML structure:
<SavingAccounts>
<SavingAccount>
<ServiceOnline>yes</ServiceOnline>
<ServiceViaPhone>no</ServiceViaPhone>
</SavingAccount>
<SavingAccount>
<ServiceOnline>no</ServiceOnline>
<ServiceViaPhone>yes</ServiceViaPhone>
</SavingAccount>
</SavingAccounts>
What I need to do is filter the 'SavingAccount' nodes using XPATH where the value of 'ServiceOnline' is 'yes' or the value of 'ServiceViaPhone' is yes.
The XPATH should return me two rows!! I can filter 'SavingAccount' nodes where both of the element values are yes like the following XPATH sample, but what I want to do is an or element value comparison???
/SavingAccounts/SavingAccount/ServiceOnline[text()='yes']/../ServiceViaPhone[text()='yes']/..
This is a very fundamental XPath feature: composing a number of conditions with the logical operators and, or, and the function not().
and has a higher priority than or and both operators have lower priority than the relational and equality operators (=, !=, >, >=, < and <=).
So, it is safe to write: A = B and C = D
Some most frequent mistakes made:
People write AND and/or OR. Remember, XPath is case-sensitive.
People use the | (union) operator instead of or
Lastly, here is my solution:
/SavingAccounts/SavingAccount
[ServiceOnLine='yes' or ServiceViaPhone='yes']
/SavingAccounts/SavingAccount[(ServiceOnLine='yes') or (ServiceViaPhone='yes')]
Will
/SavingAccounts/SavingAccount[ServiceOnline/text()='yes' or ServiceViaPhone/text()='yes']
do the trick?
I have no XPath evaluator handy at the moment.
EDIT:
If I remember correctly, you don't need the text(), so
[ServiceOnline='yes' or ServiceViaPhone='yes']
should be sufficient, and more readable.
EDIT:
Yes, of course, 'or' for predicate expressions, my bad.