Cameron Beccario : VB Language

IsNot patent

cambecc — Wed, 23 Feb 2005 07:32:00 GMT

I can't stand seeing my friends slammed on Slashdot yet again, so I'd like to say something about the "IsNot patent" fiasco. Paul, Amanda, and Corneliu are some of the nicest people I know, and I had the pleasure to work directly with them for several years. The "IsNot patent" is the result of a broken system and a litigious software industry, not the selling-out of unprincipled applicants.

TechEd part 2: Comega and VB

cambecc — Sat, 11 Sep 2004 02:05:00 GMT

Finished another day here at TechEd. Saw a presentation on Visual Studio Team System. Wow. No wonder the blogosphere is ablaze with Team System discussions. Where did they find the time to build all that stuff?

I was fortunate enough to be invited by INETA Japan to participate in a panel discussion on Cω, a "strongly typed, data oriented programming language that bridges the gap between semi-structured hierarchical data (XML), relational data (SQL), and the .NET Common Type System (CTS)." I began thinking what VB could do with Cω-like features. Some of the features such as streams, anonymous structures, and choice types seem an ill-fit for VB, but the ideas of concurrency and integrated SQL expressions are particularly appealing. Imagine an application whose memory store is implemented as a database. The benefits are obvious--sophisticated search, sort, scalability, and persistence are automatically available. Combine the database server with a garbage collector and you have a generalized memory manager, albeit one suited for web applications spread across geographically distant servers. But programming such a model today is difficult because the interface between source code and database in most languages is too complicated, not only for fetching and storing data but also for doing it in an asynchronous manner. A language that simplifies this code/database interface would be quite compelling.

The Cω feature which bothers me most is support for XML syntax. XML may be the best thing since sliced bread, but this seems done more for the sake of fashion than functionality. I see the benefits, but XML... inlined in my source code? Bleh. It's not aesthetically pleasing. I dislike XML comments for the same reason (but unfortunately they made it into VB). Perhaps I eat my own words here; SQL syntax seems similarly bolted on. I agree, but it's the idea of closing the code/database gap which is compelling, not which specific syntax is used.

Overall, though, Cω looks really neat. In particular, the SQL integration elicited oohs and ahhs from the normally reserved audience. Thanks go to INETA Japan for inviting me to the discussion.

TechEd Impressions

cambecc — Thu, 09 Sep 2004 02:27:00 GMT

I've finished my last session for the day here at TechEd. Right now I'm staring out over Yokohama Bay where the expansive Yokohama Bay Bridge dominates the view.

I attended the VB 2005 session this afternoon to see what the audience was like and what kind of topics were discussed. The room, which sits about 1200, was probably 1/3 full (the same was true for the C# session immediately following). The presentation started out with demos of new language features such as My, unsigned types, operator overloading, and generics, and ended up discussing application settings and project related improvements. I sometimes forget that there is so much more to VB than the core language. The VB language and IDE team (the folks who do Intellisense, Edit & Continue, etc.) at Microsoft has historically been around 10 people in size, but there are 20 to 30 other developers in VB working on vital features such as Data, Project, and Deployment.

Talked with a few attendees after the session and asked what they thought about the new features in VB 2005. The favorite by far was Edit & Continue. I asked about Refactoring (prominently featured in C#) and the reception was lukewarm. My Japanese isn't good enough, so I couldn't figure out the reason why.

I am surprised with how many women are attending TechEd, and I don't know whether it's Japan or a general industry trend (maybe not). We, society as a whole, need more women working in IT. The industry simply cannot grow and innovate if 50% of society's intelligence resources aren't significantly involved.

More to follow tomorrow.

An Abstract Specification for Visual Basic Late Binding

cambecc — Sun, 27 Jun 2004 09:28:00 GMT

An Abstract Specification for Visual Basic Late Binding...(read more)

The Anatomy of a Late Bound Expression

cambecc — Wed, 02 Jun 2004 02:43:00 GMT

When I first arrived at Microsoft to work on the Visual Basic team, I had no idea what Late Binding was. My manager at the time explained it to me: "Late Binding is all about figuring out which methods to call while the program runs. It's complicated. You're going to work on something else." This spawned more questions. How is it done? What happens behind the scenes? What's involved? For awhile, Late Binding remained a black box to me, but eventually I learned the answers to these questions.

The process of figuring out what methods to call and fields to use is called "member lookup and resolution", or "binding". Most of the time, the compiler binds method calls during compilation, a process we call Early Binding (well, some of us do). However, if your program uses types that aren't known during compilation, binding is deferred and instead performed while the program runs. This process is called Late Binding and is best described with an example:

Class Queen

Sub Move(ByRef x As String, ByVal y As String)

...

End Sub

Sub Replay(ByRef x As String, ByVal y As Date, ByVal z As Integer)

...

End Sub

End Class

Class Knight

Sub ResetPosition()

...

End Sub

End Class

Sub Main()

Dim a As String = ...

Dim b As Integer = ...

Dim x As Queen = ...

Dim o As Object = ...

x.Move(a, b)

o.Move(a, b)

End Sub

The expression x.Move(a, b) is a call to the method Move defined on Queen (determined from the type of variable x). The compiler, via the process of Early Binding, figures out that the text "Move" refers to method Move on type Queen, taking two String parameters. The compiler successfully analyzes this statement (i.e., binds the call) and moves to the next line.

The expression o.Move(a,b) is also a call to method Move, but on which type? The variable o is Object and can hold anything depending on the program's run-time behavior. Sometimes it might hold instances of Queen objects; sometimes Knight objects (or anything else for that matter). This is where Late Binding comes into action.

The compiler always tries Early Binding first. Move isn't a member of System.Object, so Early Binding fails. Normally, compilation stops here and a compile error results. However, because o is Object, because it can hold anything, the compiler defers binding and turns this expression into a Late Bound expression. The deferral is made by changing o.Move(a, b) into a helper function call. This helper function, which lives in the Late Binder (which itself is found in Microsoft.VisualBasic.dll), looks something like this:

Public Sub LateCall( _

ByVal Instance As Object, _

ByVal MethodName As String, _

ByVal Arguments() As Object, _

ByVal ArgumentNames() As String, _

ByVal CopyBack() As Boolean)

'implementation

End Sub

The corresponding VB code generated for o.Move(a, b) looks something like:

Dim _args As Object() = {a, b} 'temporary variable

Dim _copyback As Boolean() = {True, True} 'temporary variable

Microsoft.VisualBasic.CompilerServices.LateCall(o, "Move", _args, Nothing, _copyback)

The method we're trying to call is Move. At compilation time we know only its name, so the MethodName parameter is the string "Move". The Instance parameter is o, the object on which we want to invoke Move. And the call has two arguments, a and b, so the compiler packages them into an array and passes them to the Arguments parameter. (For now, we will skip discussion of the ArgumentNames and CopyBack parameters.)

When the program runs and the line o.Move(a, b) is reached, the call into the Late Binder is made. Because the object sitting in o has a definite type, the Late Binder has all the information it needs to bind the call to Move. It performs the full member lookup and resolution process, a process which in many ways is analogous to the Early Binding done by the VB compiler. For example, o might be an object of type Queen, so the Late Binder figures out that the string "Move" refers to method Move on type Queen, taking two String parameters. Success! The method Queen.Move is invoked and the program continues running. However, o might be an object of type Knight. Knight has no method Move, so in this case, member lookup and resolution fails and the Late Binder throws a MissingMemberException. This is the equivalent of getting the compile error "'Move' is not a member of 'Knight'" were the variable o typed as Knight instead of Object.

Now for some details that my manager, back in the day, was eluding to: ByRef parameters cause trouble. Because a Late Bound expression such as Move is working with copies of a and b (remember the Arguments parameter), we have to take special care to copy the values back out if any match a ByRef parameter. This is done by using the CopyBack parameter and some conditional statements. The CopyBack parameter is used by the Late Binder to communicate back to the call site which arguments ended up matching ByRef parameters. After the call to LateCall is completed, the Boolean values stored in the CopyBack parameter are checked and, if True, the values are copied-out. This means that along with the helper call, a Late Bound expression also consists of several If..Then statements that check the CopyBack parameter:

Dim _args As Object() = {a, b} 'temporary variable

Dim _copyback As Boolean() = {True, True} 'temporary variable

Microsoft.VisualBasic.CompilerServices.LateCall(o, "Move", _args, Nothing, _copyback)

If _copyback(0) Then

a = _args(0)

End If

If _copyback(1) Then

b = _args(0)

End If

Each True value in the CopyBack array means that the corresponding argument in the Arguments array matched a ByRef parameter and potentially changed during the call invocation. For example, since the zeroth parameter of Queen.Move is ByRef, the zeroth value in CopyBack will be set to True by the Late Binder, thus causing a to be assigned the new value.

But why initialize the CopyBack array with True values? Because there's no point checking and copying back values when the original argument isn't a storage location. To communicate this information to the Late Binder, the compiler initializes the CopyBack array with True values for each argument that comes from a variable, field, array, etc. If the argument isn't a storage location, such as a constant, function, ReadOnly property, etc., the compiler will specify False and omit the If..Then check corresponding to that argument:

o.Move(10, b)

becomes:

Dim _args As Object() = {10, b}

Dim _copyback As Boolean() = {False, True}

Microsoft.VisualBasic.CompilerServices.LateCall(o, "Move", _args, Nothing, _copyback)

If _copyback(1) Then

b = _args(0)

End If

There are even more compliations to consider when named arguments have been specified by the user. For example:

o.Replay(GetA(), z:=TimeOfDay(), y:=GetB())

Because named arguments affect binding, the Late Binder needs to know which names were specified and for which arguments. This information is communicated using the ArgumentNames string array. For example, the ArgumentNames array for the expression above would be {"z", "y"}. VB rule: once a named argument is specified in the argument list, all subsequent arguments must be named. Naturally, this requirement would force all argument values into the end of the Arguments array. However, for simplicity, we would like the same index into the Arguments array and ArgumentNames array to refer to matched value-name pairs. This means the compiler must rearrange the argument values into the beginning of the Arguments array, which would look like {TimeOfDay(), GetB(), GetA()}. Yet this tweak contains a hidden complication: order of evaluation. The evaluation of the argument list should occur lexically, left-to-right, where GetA is invoked before TimeOfDay which is itself invoked before GetB. If the Arguments array were initialized starting from the zeroth index, TimeOfDay and GetB would be invoked before GetA! This could cause serious trouble if these functions had side effects. By initializing the Arguments array in lexical order, the order of evaluation is preserved:

Dim _args As Object() = New Object(2) {}

_args(2) = GetA()

_args(0) = TimeOfDay()

_args(1) = GetB()

Dim _argnames As String() = {"z", "y"}

Dim _copyback As Boolean() = {True, False, False}

Microsoft.VisualBasic.CompilerServices.LateCall(o, "Replay", _args, _argnames, _copyback)

If _copyback(0) Then

TimeOfDay() = _args(0)

End If

(note that TimeOfDay is a read/write property and can be changed if it matches a ByRef parameter, thus the value True in the CopyBack array).

So far, I have discussed the simplest Late Binding scenario. Matters complicate yet further in other scenarios, where the call o.Move occurs on either side of an assignment:

o.Move(a, b) = c

In scenarios such as these, c must be packaged as another parameter and the whole expression evaluated as a possible Property or Field assignment (with a potential intermediate Default Property access). In fact, each of the following forms represents a unique Late Binding scenario:

o.Move(a, b)

o.Move(a, b) = c

c = o.Move(a, b)

o(a, b) = c

c = o(a, b)

Only the first statement corresponds to the LateCall helper we've been analyzing. The other scenarios each have their own helper with various additional arguments to control the unique semantic differences that arise.

I want to briefly describe what the LateCall helper actually does. The following is a very rough implementation and demonstrates how the VB Late Binder interacts with System.Reflection:

Public Sub LateCall( _

ByVal Instance As Object, _

ByVal MethodName As String, _

ByVal Arguments() As Object, _

ByVal ArgumentNames() As String, _

ByVal CopyBack() As Boolean)

Dim T As Type = Instance.GetType

Dim Members As Reflection.MemberInfo() = T.GetMember(MethodName)

Dim Result As Reflection.MemberInfo = _

PerformMemberResolution(Members, Arguments, ArgumentNames)

Select Case Result.MemberType

Case MemberTypes.Method

Dim MethodResult As MethodInfo = DirectCast(Result, MethodInfo)

MethodResult.Invoke(Instance, Arguments)

For Each P As ParameterInfo In MethodResult.GetParameters

If P.ParameterType.IsByRef Then

CopyBack(index_of_P) = True

End If

Case ...

End Select

End Sub

First, Reflection is used to fetch all the members matching MethodName into an array. This array, along with Arguments and ArgumentNames, is passed to a function PerformMemberResolution. This function is responsible for implementing all of Visual Basic's binding semantics, including name shadowing, method overload resolution, named argument matching, and various other checks. However, selecting the method is only half the work. Once a selection is made, the member must be invoked. In the case of methods, this is done via the Reflection.MethodInfo.Invoke member. Once execution of the method is complete, the CopyBack array is populated with the correct values and the Late Bound expression is complete.

I should have listened to my manager. :)

Operator Overloading

cambecc — Tue, 21 Oct 2003 03:36:00 GMT

One of the new features we're adding to Visual Basic is called Operator Overloading. This feature allows the programmer to create a class that knows what +, -, *, and other operators mean.

There are two main components to operator overloading: consumption and declaration. (Actually, I've just described a major precept of language design. Although they go hand-in-hand, the declaration form of a feature and the consumption form of a feature are two intrinsically different concepts. The dichotomy reveals itself even in .NET executables. When people talk about "metadata", they are referring to declarations. When people talk about intermediate language (IL) opcodes, they are referring to consumption.)

Let's take a look at consumption first with an example.The System.Drawing namespace contains the types Point and Size. A new point can be calculated by adding or subtracting a size from an already existing point. Programmatically, the + and – operators lend themselves naturally to this calculation:

Dim p1 As New Point(10, 10)

Dim s1 As New Size(20, -10)

Dim p3 As Point = p1 + s1

Dim p4 As Point = p1 - s1

MsgBox(p3.ToString)

MsgBox(p4.ToString)

Because Point overloads the + and - operators, this code compiles and works as expected, outputting:

{X=30,Y=0}

{X=-10,Y=20}

How was this done? When the compiler analyzes the expression "p1 + s1", it discovers the type of "p1" is Point and that Point defines Operator +. Operators are actually just functions with funny names, so the compiler turns "p1 + s1" into a function call, equivalently written as:

Dim p3 As Point = System.Drawing.Point.op_Addition(p1, s1)

This is the key to understanding overloaded operators: they are just functions. An expression like "a + b" is really a call to the + operator with two arguments: "+(a, b)". Because member names cannot contain symbols like "+", the compiler uses a special name behind the scenes: "op_Addition(a, b)". And as functions, the compiler uses normal overload resolution rules to pick the correct overload (in exactly the same way the compiler uses these rules to pick the correct overload of Console.WriteLine, which at last count had 19 overloads!).

Perhaps you can guess what the declarations of overloaded operators look like; they're an awful lot like functions:

Public Shared Operator +(ByVal Left As Point, ByVal Right As Size) As Point

Return New Point(Left.X + Right.Width, Left.Y + Right.Height)

End Operator

Public Shared Operator -(ByVal Left As Point, ByVal Right As Size) As Point

Return New Point(Left.X – Right.Width, Left.Y – Right.Height)

End Operator

The Visual Basic compiler will allow you to overload several operators, summarized in the table below:

+	+ (unary)
-	- (unary)
*	\
/	^
&	Like
Mod	And
Or	Xor
Not	<<
>>	= (comparison only)
<>	<
<=	>
>=	CType
IsTrue	IsFalse

CType, IsTrue and IsFalse are special and I'll cover those in a future entry. But quickly, you can overload conversions between types using the CType operator (instead of overloading the = assignment operator). And IsTrue and IsFalse are for overloading AndAlso and OrElse which are themselves not directly overloadable.

A few rules greatly simplify the design and use of operator overloading: each operator declaration must be Public and Shared, and must be declared in the same type as one of its operands. And some operators, like <= and >=, must be pair-wise declared, i.e., a declaration of one requires an identical declaration of the other. You'll find, as I did, that these simple rules make understanding operator overloading much, much easier.

More info to follow...

Unsigned Types

cambecc — Tue, 19 Aug 2003 00:38:00 GMT

As you may have seen on the roadmap (http://msdn.microsoft.com/vstudio/productinfo/roadmap.aspx), we've been working on several new language features for VB .NET. One of them includes unsigned types. Yes, VB is finally getting unsigned types, and this will make some tasks a lot easier.

Specifically, we are adding intrinsic support for four new integral types, three of them unsigned, one of them signed. Here's a table which describes the new types:

VB Keyword	Conversion Operator	Type Character	CLR Name
SByte	CSByte(o)	--none--	System.SByte
UShort	CUShort(o)	US	System.UInt16
UInteger	CUInt(o)	UI	System.UInt32
ULong	CULng(o)	UL	System.UInt64

For consistency with earlier versions of VB, the name of the original type makes up the root of the new name, prefixed by a U (or S) to denote the signededness of the type. We used a similar approach to name the conversion operators and type characters. SByte has no type character because Byte has no type character.

Here's a code snippet which uses each of these new types:

Module Module1

Sub Main()

Dim a As SByte = -127

Dim b As UShort = 65535

Dim c As UInteger = 4294967295

Dim d As ULong = 18446744073709551615UL

Dim o As Object

o = CSByte(42)

a = CSByte(o)

o = 42US

b = CUShort(o)

o = 42UI

c = CUInt(o)

o = 42UL

c = CULng(o)

End Sub

End Module

Of course, this snippet is a contrived example demonstrating the new syntax. Here's a real-world example:

Module ExternalFunctions

Structure INFO

Public KIND As UShort

Public FLAGS As UShort

Public DATA As UInteger

End Structure

Declare Auto Sub GetData Lib "mylib" (ByRef Info As INFO)

Declare Auto Function GetCount Lib "mylib" _

(ByVal Index As UInteger) As UInteger

Sub Enumerate()

For i As UInteger = 0 To GetCount(10)

Dim Info As INFO

GetData(Info)

Console.WriteLine(Info.KIND)

Console.WriteLine(Info.DATA)

End Sub

End Module

One final note: unsigned types also affect method overload resolution. If two methods are equally applicable because the argument types do not exactly match the signature, yet the methods differ only by the signededness of a parameter, the method with the signed parameter wins (except for SByte and Byte, where Byte wins). This rule reduces the occurrence of ambiguity errors.