One of the problems that we’ve run into when trying to get new platforms such as the Compact Frameworks or Silverlight to support Visual Basic is getting the VB runtime supported on the new platform. The VB runtime, besides having a bunch of user functions such as Left and MsgBox and such, contains a number of language helper functions that are required for the correct functioning of the language. For example, when you convert an Integer value into a String value, we emit a call to a helper that does the conversion for you, since there is no native IL instruction for this. The number of situations where we emit helper calls isn’t huge, but there are some core features of the language that just won’t work without them. This is why there’s been no officially supported way to remove the reference to Microsoft.VisualBasic.DLL.

More than the language, though, the problem is that the compiler won’t work without the helpers, either. Basically, the VB compiler will just crash when it fails to find a VB runtime helper. Even if you’re careful to avoid features that don’t use helpers, it still doesn’t mean you can just run without a reference to Microsoft.VisualBasic.DLL–there are still many cases where we sanity check for helpers even if we aren’t going to use them. Which means that even if you managed to figure out how to get the compiler to not reference Microsoft.VisualBasic.DLL, it was likely that lots of things aren’t going to work.

As we faced the prospect of more and more platforms starting to support .NET, we realized that we needed to do something about this situation in Orcas. So we did a feature we’ve been calling “runtime agility.” The runtime agility work basically enables new platform developers to compile without a standard reference to Microsoft.VisualBasic.DLL and we’ll only barf on missing runtime helpers if you try to use a feature that requires them. And when we do barf, we give you a nice error message telling you what helper was missing instead of just crashing. You can also redirect the VB runtime reference to another DLL if you’re building a new one for your platform. For platform developers, this means that they can more easily develop a VB runtime DLL for their platform without having to stub in a bunch of helpers that they don’t support. And, yes, if you really want to run without a VB runtime, you can now do that.

This switch is only supported on the command-line for Orcas–there’ll be no UI expression of it. The switch is “/vbruntime” and should show up, I believe, in Beta2.

As many people know by now, Microsoft has decided to reschedule the PDC that was planned for later this year. This was very disappointing for me personally, since I was looking forward to seeing a bunch of the people that I usually see there and was one of the consolations I had for myself for not being able to go to MIX. It also means that our plan to talk more about VBx at the PDC is going to have to be shifted around. Not clear where/when our focus is going to move to, but stay tuned, we should have more information shortly…

As is always the case in a major release, there are a number of smaller features that don’t get very publicized because they’re not as big or sexy as the major features. One that someone asked me about privately in email was partial methods. VB will support them in pretty much the same way that C# does. In fact, rather than writing a big, long entry about it, you could just check out Scott Wisniewski’s excellent entry on them. You can also check out Wes Dyer’s excellent entry on them for C#.

How’s that for lazy?

Updated 05/30/2007: Somehow I’d missed the fact that one of our own wrote a whole entry on them on the VB blog! Eek! My apologies to Scott for missing his entry and check it out!

Yes, it’s true, as Miguel found out at the compiler lab:

Another interesting detail: the new Javascript compiler is written in Visual Basic.NET.

The compiler he’s talking about is the Silverlight-based Javascript compiler that we released in Silverlight 1.1. Of course, we’re also writing VBx in VB as well, so…

About a month ago, the C# team announced that they were making anonymous types immutable in C# 9.0. The issues with mutable anonymous types are pretty well described in Sree’s blog entry, but what it boils down to is this: in several places in LINQ, anonymous types are used as keys for things like grouping and filtering. For example, if you group customers by state and country, then the grouping is done on a composite key made up of the State field and the Country field in an anonymous type. To enable keys to be used to do grouping efficiently, they have to expose a stable hash value. That is, once a key has been constructed, it always needs to return the same hash value.

The problem was that anonymous types base their hash value on the hash values of the constituent members of the type. If those values are mutable, then that means that the hash value is mutable. Which means that the hash value might not be stable, which means that it might be possible to really hork up LINQ queries by accidentally changing keys during an operation.

In looking at this problem, though, we didn’t want to throw the baby out with the bathwater. Anonymous types are somewhat limited at the moment because they cannot be named, but you can use late binding to work with them even outside of the context in which they were declared. And future features that we’re interested in exploring, such as nominal anonymous types and dynamic interfaces, may make anonymous types even more useful. As such, it seemed too drastic to simply make them immutable, especially because this would be a one-way decision–once they were immutable, compatibility would make it extremely difficult to make them mutable again in the future if it become more desirable to do so.

At the same time, it occurred to us that the problem we’re dealing with here–generating hash values–is one that applies to many situations, not just anonymous types. Generating hash values is a common operation for types, and making it easier to do that right seemed to be a win. So instead of changing the way anonymous types work, we’ll be introducing in Beta 2 a way to more easily generate a correct hash value from a type. For Orcas, this will be limited to anonymous types, but beyond Orcas, we’d like to generalize this to all types.

In Beta 2, you will be able to specify a Key modifier on a field of an anonymous type (i.e. “New With { Key .Country = “USA”, Key .State = “WA” }”). This modifier will do two things: one, it will make the field read-only (since keys have to be stable), and two, it will cause GetHashCode to be overridden and call the GetHashCode of the key field. You can have as many Key fields as you like, and the hash codes of all the keys will be combined. The LINQ query expressions will automatically use Key fields in any situation where a key is going to be generated (for example, Group By), but you will need to include the Key modifier if you are calling the LINQ APIs directly. Post-Orcas, we’d like to generalize this concept to all types and allow you to declare Key properties or fields, and do the same thing as with anonymous types. This will, we hope, simplify the work of making types that can be easily hashed.

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!