Many months ago, I discussed the fact that we were finally planning to come up with a true ternary conditional operator that would allow short-circuited conditional expressions. (Just as a quick recap: the current problem with the IIF function is that it evaluates all the arguments since it is just a regular method call. So “IIF(x Is Nothing, “Empty”, x.Name)” will throw an exception if x is Nothing, because we still evaluate x.Name.)

At the time, we were considering taking the IIF function and making it intrinsic. In the end, this looked like it would just be too big of a compatibility problem. There were lots and lots of subtleties around the return type and the short-circuiting behavior that were going to pose problems. So instead we simply reused an existing keyword and invented a whole new operator–the If operator. The If operator works just the way you’d expect it–it evaluates the first operand and if it is True, evaluates and returns the second operand. If it it’s False, then it evaluates the third operand and returns that. There is also a binary form of the If operator that takes a reference type or a nullable value type as its first operand. If the value is not Nothing, then the first operand is returned. If the value is Nothing, the second operand is returned. This is useful for doing a database coalesce operation, something like “If(x.Name, “<no name>”)”.

The result type of an If operation depends on the types of the two operands that might be returned from the operation. In general, we pick the wider of the two types. If the two types don’t convert to each other, then you get an error. (For example, if you did “If(<boolean>, <integer>, <long>)”, the result type would be long. If you did “If(<boolean>, <Button>, <string>)”, you’d get an error because there was no conversion between Button and string.)

One question people might have is, “why the parenthesis?” More than a few people have suggested an expression form of the If statement, something like “x = If y Is Nothing Then “<none>” Else y” or other variations that weren’t delimited by parenthesis. In the end, most everything that didn’t use parenthesis as delimiters just ended up looking funny when you put it in an If statement (“If z = If y Is Nothing Then “<none>” Else y Then…”) or funny when you strung a few of them together using AndAlso/OrElse. For what it’s worth…

The If operator won’t appear in Orcas until Beta2, unfortunately. So you’ll still have to wait a bit longer…

(And, as a final piece of trivia, why is the IIF function called “IIF?” It stands for “Immediate If“.)

One. Just one. VBx is the next version of Visual Basic, not a new version of Visual Basic.

Part of the confusion stems from the fact that there are TWO ways you can use Visual Basic in Silverlight, and one uses Orcas and one uses VBx. So let me see if I can clarify a little bit…

As everyone should be aware now, Silverlight is a cross-platform version of the CLR. This means that Silverlight, with some limitations, can run any compiled IL application or library that the desktop CLR can run. This also means that (again, with some limitations) Visual Basic applications or libraries that have been compiled into IL on the desktop can be downloaded and run on Silverlight. If you go and read Joe’s VB on Silverlight entry, he points you to how you can do this today–build a VB application or library using Orcas Beta 1 and then run it on Silverlight.

You’ll notice that what you have to do in this scenario, though, is compile your application or library on the desktop and then run it in Silverlight. You can’t take your application or library in source code form, send it to Silverlight and have it compiled on demand within Silverlight itself, because the Orcas Visual Basic compiler isn’t a part of Silverlight. So, for example, if I was to embed a Silverlight application in a web page viewable on the Mac, I have to build my libraries ahead of time and deploy them to the web server to be downloaded when someone hits the page.

What John and Jim demoed, and what the DLR enables, however, is a second scenario. Because the DLR is managed code, it can be run directly on Silverlight. This means that you can actually get a running instance of a DLR language within Silverlight itself. So instead of having to compile an application or library before you can use it in Silverlight, you can simply include the code as a part of the Silverlight application, and the code can be compiled by the DLR language on the fly. This enables the traditional style of client-side applications that you see in AJAX or other libraries. Instead of compiling the library ahead of time, you simply download the client code to the browser when it hits the page, and the code will be compiled and run within the browser in real time.

This is where VBx, the next version of Visual Basic, comes in. Part of VBx is a hostable managed component (written in Visual Basic, no less!) built on top of the DLR. Since Silverlight can host DLR languages, this enables you to send Visual Basic code to a Silverlight instance and have it dynamically compiled and run. So when the Mac hits your webpage, you don’t have to send a binary at all, you can send just source code. When you want to modify your application, you don’t rebuild, you just modify the source code sent to the browser and refresh the page and there you are!

The important thing to keep in mind is that there is still only ONE Visual Basic language but once VBx arrives you’ll have more than one way of getting to it. You’ll still be able to compile code into the traditional .DLL or .EXE, but you’ll also have the option of compiling and running the code on the fly, within a running instance of the CLR. That’s where things are likely to get interesting…

There was a semi-announcement as a part of the Silverlight 1.1 discussion at MIX07 yesterday that people might be wondering about.

If you check out the Silverlight poster that Brad posted a pointer to, you’ll see that on the right hand side under the box that says Framework Languages, there are TWO listings for Visual Basic. First, there’s “Visual Basic” and then down at the bottom there’s a “VBx” with a little icon “Soon.” Then, if you look at Jim Hugunin’s blog entry on the Dynamic Language Runtime (DLR), you’ll see that he says (emphasis mine):

We’re initially building four languages on top of the DLR – Python, JavaScript (EcmaScript 3.0), Visual Basic and Ruby. We shipped today both Python and JavaScript as part of the Silverlight 1.1alpha1 release today. John Lam and I will be demoing all four languages, including VB and Ruby, working together during our talk tomorrow at 11:45.

And then if you go on to Jason Zander’s blog entry on .NET Framework support in Silverlight, he says (again, emphasis mine):

With the new DLR, we have support for IronPython, IronRuby, Javascript, and the new dynamic VBx compiler.

And, finally, you can go to Amanda Silver’s entry on what the MIX07 announcements mean for the VB developer to get a few more hints.

So, what does this all mean, exactly? What is this “VBx” thing? What are we up to?

Well, as I’ve been hinting at for a while now, there’s been something I’ve been working on quite a lot in recent months that I couldn’t talk about. With our announcements at MIX07, though, I can now take a bit of the wraps off. “VBx” is our current (subject to change) codename for the next major version of Visual Basic. (The “x” is supposed to signify the Roman numeral X, or 10, since the next major version of Visual Basic is going to be 10.0. The “x” really should be capitalized, but some people were worried there’d be confusion with the old VBX controls. Not that the search engines are really going to draw a distinction. Like VB itself, they’re mostly case insensitive.)

Now, at this early stage of the game, the full shape of the next version is sketchy at best. We’re not done with Orcas by any stretch of the imagination. We haven’t even started the formal planning for process for anything beyond Orcas yet. However, there are several features that we are clear, even at this early stage of the game, that we are going to want to support in the post-Orcas timeframe:

• Visual Basic should become a hostable language that can be easily used to do application scripting, akin to what you could do with VBScript and VBA. Furthermore, this hostable language engine should be fully portable to all platforms supported by the CLR, including all platforms supported by Silverlight (such as client-side scripting in the browser on a Mac…).
• The performance of dynamic binding (a.k.a. late binding) should be as close to static binding as humanly possible.
• Dynamic method and type generation should be fully supported and consumable in the language.
• Visual Basic should fully support a REPL (Read-Eval-Print Loop). This means taking the support we already have for a REPL in the immediate window in VS and both extending it to the full language and adding the ability to host the REPL outside of Visual Studio.

If you look at this feature list, much of it is congruent with the mission of the Dynamic Language Runtime (DLR). Consequently, we’ve been working very closely with the DLR team to start prototyping many of these features in Visual Basic. If you were at the MVP summit or went to Jim and John Lam’s talk at MIX yesterday, you’ll have seen this prototype–which, again, we’re calling “VBx” for the moment–in action. Amanda and I will be working on some screencasts and other stuff to show this to the world in the near future, but it is, in essence, the fusion of the Visual Basic language services and the DLR. This gives us many of the features listed above, and more. (For example, because VBx is built on top of the DLR, it automatically interoperates with any other dynamic language built on the DLR. So VBx code can interact seamlessly with libraries written in Python, Javascript, or Ruby, and those languages can interact seamlessly with code compiled by VBx.)

As excited as we are about VBx, it is, unfortunately, not part of the Silverlight 1.1alpha1 released yesterday. Although we have a significant amount of functionality already implemented there is still more work to be done to bring the VBx language support up to the level that we feel is necessary for a productive community preview. Our plans are to have a community preview out later this year, and to talk much more detail about VBx at PDC07. In the meantime, though, we will be discussing VBx here on my blog and on the VB team blog, so keep your eyes peeled!

My +1 link postings are always the last ones in to the pool, but in case you haven’t seen it elsewhere, Beta 1 of Visual Studio Orcas is now available for download! This has a large majority of the Orcas features for VB in it, although there are still some features that will be coming in post-Beta1 (lambdas, nullable types, etc.) because of the way the schedule came together. (You can find more details about new features in Beta1, such as “Intellisense everywhere” on our team blog.)

I’ve been writing a LOT of Visual Basic code in the past couple of months, and this is making me excited to work towards getting off of VB 2005 and on to Orcas…

Check it out!