The Visual Basic Team : Timothy Ng

Where is the VB Team going to be over the next few months? (Lisa Feigenbaum)

VBTeam — Mon, 29 Sep 2008 01:26:00 GMT

We have quite a few trips coming up over the next couple months, and we want to connect with you while we’re on the road. Here is our plan. Let us know where we can find you. ;-)

October 6-7, 2008

Software Development Conference 2008: http://www.sdc.nl/

Beth Massi

October 8-10, 2008

TechEd Hong Kong: http://www.microsoft.com/hk/technet/teched2008/

Karen Liu

October 21-23, 2008

OOPSLA: http://www.oopsla.org/oopsla2008/

Dustin Campbell

October 27-30, 2008

Professional Developers Conference: http://www.microsoftpdc.com/

Paul Vick

Dustin Campbell

Lisa Feigenbaum

Alex Turner

November 8-9, 2008

Silicon Valley Code Camp: http://www.siliconvalley-codecamp.com

Tim Ng

Beth Massi

November 10-13, 2008

DevConnections: http://www.devconnections.com/shows/FALL2008VS/default.asp?c=1&s=121

Lucian Wischik

Jay Schmelzer

Christin Boyd

John Stallo

November 10-14, 2008

TechEd EMEA: http://www.microsoft.com/emea/teched2008/

Jonathan Aneja

Lisa Feigenbaum

Karen Liu

Paul Yuknewicz

John Durant

November 17-20, 2008

Spain user group tour, Barcelona to Madrid

Jonathan Aneja

Lisa Feigenbaum

November 19-20, 2008

TechSummit Berlin: http://www.technical-summit.de

Paul Yuknewicz

John Durant

December 1-2, 2008

DevTeach Montreal: http://www.devteach.com/

Beth Massi

January 7-9, 2009

Code Mash: http://www.codemash.org/

Dustin Campbell

Finally, you can also find us at the .Net Developers Association meeting in Bellevue, Washington the fourth Monday night each month. http://netda.net

LINQ to SQL (and LINQ to Entities) performance improvements (Tim Ng)

VBTeam — Fri, 28 Mar 2008 18:58:00 GMT

Over the last few months, the VB and Data Programmability teams were working on fixing a performance problem with LINQ to SQL (which also manifested in LINQ to Entities). The issue was that LINQ to SQL was generating sub optimal T-SQL queries when the VB LINQ queries included filters over nullable columns.

For example, consider the following query:

Dim q = From o In db.Orders Where o.EmployeeID = 123 Select o.CustomerID

In this scenario, the Orders.EmployeeID field is a nullable field (Integer?). In VB, the logical operators (<. <=, =, etc) are considered "three-value" operators, and thus, the result of the equality comparison is a “Boolean?” however, the LINQ operators expect the predict to return “Boolean” and not “Boolean?” therefore, VB must convert the “Boolean?” to a “Boolean” using the Coalesce operator. (For more details, please see my blog post on Expressions trees and Coalesce ).

Although LINQ to SQL could optimized out the Coalesce operator, in VS 2008 RTM it converted from a predicate logic to value logic (and vice versa) which in some cases blows the applicable index on the column.

Here's an example for the SQL that is generated in VS 2008 RTM:

SELECT [t0].[CustomerID]
FROM [dbo].[Orders] AS [t0]
WHERE (COALESCE(
    (CASE
        WHEN [t0].[EmployeeID] = @p0 THEN 1
        WHEN NOT ([t0].[EmployeeID] = @p0) THEN 0
        ELSE NULL
     END),@p1)) = 1
-- @p0: Input Int (Size = 0; Prec = 0; Scale = 0) [123]
-- @p1: Input Int (Size = 0; Prec = 0; Scale = 0) [0]

The Good News

The good news is that the LINQ to SQL team has a fix to their code generation to recognize this pattern, and now they emit the SQL code that you would have expected to emit:

SELECT [t0].[CustomerID]
FROM [dbo].[Orders] AS [t0]
WHERE [t0].[EmployeeID] = @p0
-- @p0: Input Int (Size = 0; Prec = 0; Scale = 0) [123]

In other words, LINQ to SQL (and LINQ to Entities - we made the same fix there) is now smart enough to pass three-value logic from VB to SQL.

In this particular case, both VB and SQL employs three-value boolean logic, but the intermediate layer (the LINQ operators), employed two-value boolean logic, and the translation between the layers was "lost", which resulted in the non-optimized code that we generated in VS2008 RTM. Look forward to this in an update coming later this year.

VB expression trees - string comparisons

VBTeam — Wed, 19 Sep 2007 09:14:12 GMT

Hey there!

Last time, I talked a little bit about expression trees and what they are useful for. Expression trees are really interesting to those who want to write LINQ providers and have the ability to reason about the lambda expressions coming into their LINQ provider. However, in general, anyone that want's to reason about a lambda expression should be interested in expression trees.

Today, I'm going to write particularly to those who are implementing code that reads expression trees. Even if you don't plan to do that, I hope you follow along because this stuff is interesting to know and understand regardless :)

For this post, I wanted to discuss the comparison of strings and their representation in expression trees. Jonathan (our PM) and I were working through a LINQ provider sample, and we thought that this code would be useful to share with you.

In Visual Basic, it's possible to cause the = operator to do either case sensitive or case insensitive string comparison, via the option compare configuration.

In order to implement these semantics, the Visual Basic compiler emits a call to Microsoft.VisualBasic.CompilerServices.Operators.CompareString in the Visual Basic runtime. This method takes 3 arguments; the two operands, and a flag indicating the comparison type.

When the Visual Basic compiler generates an expression tree for a string equality operator, we decided to encode a call expression to the CompareString method in order to preserve the correct string comparison semantics. This is because by default, the Equal node in the expression tree API assumes case sensitive comparisons. Furthermore, the Equal node doesn't take into account special VB semantics around string comparisons and the Nothing literal.

This means that if you are writing a visitor over the expression trees generated by the VB compiler, you should expect to see a binary operator for <, <=, =, >=, or >, where the left hand side is a CompareString method and the right hand side is 0. When you see this, you should unpack the arguments in the CompareString method and apply the right string semantics based on the 3rd argument to CompareString.

However, if your provider doesn't care about string comparison semantics (LINQ to SQL, for example, doesn't care), then you can use the following code to transform the binary operator for the method call to a binary operator for the method call arguments, ignoring the string comparison semantics.

Call this method in your visitor for binary expressions, and it will convert it appropriately for you. You can then run your visitor over the node returned by this method, and handle string comparison as a binary operator, but you lose the case sensitivity of the comparison.

Friend Shared Function ConvertVBStringCompare(ByVal exp As BinaryExpression) As BinaryExpression
    If exp.Left.NodeType = ExpressionType.Call Then
        Dim compareStringCall = CType(exp.Left, MethodCallExpression)
        If compareStringCall.Method.DeclaringType.FullName = "Microsoft.VisualBasic.CompilerServices.Operators" _
            AndAlso compareStringCall.Method.Name = "CompareString" Then
            Dim arg1 = compareStringCall.Arguments(0)
            Dim arg2 = compareStringCall.Arguments(1)

            Select Case exp.NodeType
                Case ExpressionType.LessThan
                    Return Expression.LessThan(arg1, arg2)
                Case ExpressionType.LessThanOrEqual
                    Return Expression.GreaterThan(arg1, arg2)
                Case ExpressionType.GreaterThan
                    Return Expression.GreaterThan(arg1, arg2)
                Case ExpressionType.GreaterThanOrEqual
                    Return Expression.GreaterThanOrEqual(arg1, arg2)
                Case Else
                    Return Expression.Equal(arg1, arg2)
            End Select
        End If
    End If
    Return exp
End Function

Here's an example of how you can use this. This is a really trivial visitor that doesn't do anything useful, but I just wanted to show how you could use the method defined above.

Sub VisitBinary(ByVal exp As BinaryExpression)
    exp = ConvertVBStringCompare(exp)
    Visit(exp.Left)
    Visit(exp.Right)
End Sub

I hope that this helps!

Tim

Lambda Expressions and Expression Trees

VBTeam — Wed, 12 Sep 2007 05:10:30 GMT

Hi there!

My name is Tim, and I'm the dev lead for the VB compiler team. Recently Amanda convinced me to blog on the VB team blog rather then my own blog for a variety of reasons, and so here I am. My current plan is that I'll post VB related postings here, and more compiler implementation/technology/fun facts on my own blog (ie, things that don't relate to the VB language/features).

Recently my article on lambda expressions got published on MSDN magazine. For this blog post, I'm going to expand on some of the ideas in that article, so feel free to check out the article if some of the ideas here don't make sense yet.

Lambda expressions are really cool not only because of the reasons stated in the article, but also because it's possible to capture the contents of a lambda expression in a readable form and treat it as data rather than executable code.

For example, the following line of code turns a lambda expression into a callable delegate:

Dim f As Func(Of Integer, Integer) = function(x) x * 2
Dim r = f(10)

In this code sample, the first line creates a lambda expression and does the magic to assign it to a callable delegate f, and the second line invokes f and returns 20.

This is all cool, and I hope my article highlights some of the reasons why I think this is cool. What's even more cool is that you can actually assign a lambda expression into a special variable type and the compiler does some more magic for you:

Dim e As Expression(Of Func(Of Integer, Integer)) = function(x) x * 2

In this code sample, e is not a callable delegate. Rather, it's an expression tree. An expression tree is a data representation of the lambda expression in a form that is easy for you to read and reason about the lambda expression in.

If you look through the value of e in the debugger, you'll see that you can easily determine that the expression was a multiplication operation of variable called x of type integer with a constant integer 2.

By default, query operators that extend IEnumerable take lambda expressions. Query operators that extend IQueryable take expression trees. Therefore, when you issue a query over a type that is queryable, the compiler will generate an expression tree rather than a lambda expression.

Scott, one of the developers on my team, has written an excellent article as well on some of these ideas. He has a great diagram there showing the expression tree representation of a few lambda expressions.

What can you do with expression trees?

In general, you can do 2 things:

Reason about the data in the expression tree, and do custom processing over it. You can also convert the data in the expression tree into another domain (such as XML).
Use the .Compile() method to turn the expression tree into a delegate so that you can execute it.
Build queries with dynamic conditions: see Jonathan's (our PM) excellent post. He has a great example of how you can manipulate the expression trees and build custom conditions in your lambda expressions.

Item 2 is interesting, because it means that you can write a lambda expression into an expression tree, reason about it, etc, and then turn it into a callable delegate.

Dim e As Expression(Of Func(Of Integer, Integer)) = function(x) x * 2
Dim f = e.Compile
Dim r = f(10)

In this example, the value of r is 20, just like the previous example where we assigned the lambda directly to a delegate type.

Why is this interesting?

Without expression trees, its impossible to describe expressions in a descriptive format; the only description of them is IL, which is too low level to re-create the user's intent for the expression. Rather, expression trees provide a high level tree representation of an expression, so that you can easily understand the user's intent for the expression.

Here are some uses of expression trees that may be interesting:

Reason about expressions, then convert them to delegates and call them.
Convert expressions into SQL so that they can be executed by a server (this is what LINQ to SQL does).
Convert expressions into XML and write them to disk.
Convert expressions into a custom format to send over a network protocol to a server that can then rebuild the expression tree from the format, recreate the expression, and reason about it and/or execute it.

Over the next several posts, I'm going to blog specifically about the expression trees that the VB compiler generates, and some differences between C# trees and VB trees in order to maintain VB semantics. I will also provide tips on things you can do to be sure that any library that you write that consumes expression trees will provide the best experience for VB developers.

Tim