One of the side projects that I’m working on in addition to this weblog is a managed scanner and parser for the Visual Basic .NET language. I started on the project because I’d really like to write some project analysis tools that I could use to determine things about how people use the language, but as it’s gone on I’m hoping to also release it into the community as a sample. (One of the wrinkles is that I’m “writing” the managed parser by looking at the existing unmanaged parser, so it’s not like the code I’m writing is completely of my own invention, although it is largely so.) I think that the more that people can work with a language in an automated way, and the more tools people can write for a language, the better it is for people who use that language. Anyway, we’ll just have to see. I still have to finish it first…

After I finished the scanner (scanners are easy), I started parsing expressions and have been working my way up the parse tree hierarchy. I’ve recently reached type members and, in particular, methods. An interesting thing is the way that VB’s line orientation interacts with MustOverride methods when parsing. In C#, parsing methods is pretty simple because after a method header you can see either a semicolon or an open curly brace. If it’s the former, then you’ve got an abstract method declaration; if it’s the latter, then you’ve got a concrete method declaration. Whether or not you specified abstract as a modifier on the declaration is really something for declaration semantics to sort out later on. In VB, though, the following fragment is ambiguous if you don’t look at the modifiers:

<modifiers> Sub Foo()
Dim Bar As Integer

In other words, once you’ve gotten through the method header, the next line starts with Dim, which could either mean that Foo was a MustOverride method and Bar is a field, or that Foo was a concrete method and Bar is a local. To figure out which is which, you absolutely have to look at the modifiers to see if MustOverride is there. This is the kind of thing that drives formal grammar writers nuts because it means you have to hork up your grammar productions to make it all come out right. It doesn’t make such a big deal, though, if you hand-code your parser, which is what we do for VB. (Hand-coded parsers vs table-driven parsers seems to be one of those religious arguments that language people get into. Let me just say I don’t take a formal position on the question.)

Interestingly, there are at least a few other places in the language (esp. in terms of object creation expressions versus array creation expressions) where things get complicated like this. But overall, it’s been pretty smooth sailing. I’ll let everyone know as the project progresses.

Duncan points out a little something extra that VB.NET’s Try...Catch syntax supports. It’s something the underlying IL supports and it seems useful, so we figured, why not? A use that comes to mind is when dealing with COMExceptions:

Try
    ' Do some COM interop
Catch ex As COMException When ex.ErrorCode = &H80043919
    ' Handle this specific error
End Try

Nothing fancy, just a little something extra. An interesting thing to note is that the CLR doesn’t actually support specifying both a type filter (i.e. ex As COMException) and a filter expression (i.e. Where ex.ErrorCode = &H800043919), so the above Catch clause is a filter expression that checks both the type and the value together. It doesn’t use a type filter. I was never really clear why the CLR did it that way, but it’s not a big deal either way.

Cameron’s blog also reminded me that we’ll both be participating in a chat (along with other team members) on Tuesday, July 29th, 2003. Do feel free to join us. Here’s the blurb, copied from Cameron:

http://msdn.microsoft.com/chats/

Date: Tuesday, July 29
Time: 1 PM to 2 PM
Title: Chat with the Visual Basic .NET Team: Language Design
Summary: Do you have questions about why Visual Basic .NET is the way that it is? Join Paul Vick, the architect of the Visual Basic .NET Language Specification, and other members of the Visual Basic .NET team for a wide-ranging discussion on the Visual Basic language. Learn the reasoning being the design choices and discover how to write more powerful applications.

I do have to say I find the summary a little frightening, though…. I hope I can live up to it!

Another member of the VB.NET team has started a weblog, this one hosted on GotDotNet. His name is Cameron Beccario and he knows a whole lot about the language and the compiler as well. He was kind of bummed to find out that I’d already written about DirectCast, so I think what this means is that we’re going to be competing with each other to get the good tidbits about the language out before the other guy. And who wins, gentle reader? You do, of course!

Eric points to an editorial from Visual Studio Magazine that I think is really spot-on, although I think the title is a bit of a misnomer.

Patrick is, I think, accurate about some of the whys and wherefores of VB.NET’s history, and about the need to recapture some of what has been lost in the transition to .NET. There’s no question, for example, that not having edit and continue has been a huge loss, something that has been keenly felt within the company as well as without. It’s going to be a major feature in Whidbey and one I’m very excited about getting back. (I’d better be, since one of the things I’m supposed to do is make sure we do edit and continue right. If it’s wrong, my head is going to be one of those on the block…) And there’s even more stuff that we’re working on in addition to that, but we’ll get to that later, I hope…

The only issue I have with the editorial is the use of the phrase “language divergence.” The phrase is problematic because it’s so general that it can mean a lot of things that are not what we’re working towards. For example, it doesn’t mean that VB.NET is going to stop providing excellent support for the platform. It also doesn’t mean that we’re going to try and “dumb down” the language or compromise on the power and flexibility that we afford developers today. What it does mean, to us at least, is that VB is not just “C# without braces.” Our goal is not to just ape whatever another language does, our goal is to server our customers as best as we possibly can. If that means that we do some things differently than C# does, then we’ll do them differently. If that means we do some things the same way as C#, then we’ll do them the same way. Some people (not Patrick) have used “language divergence” as a shorthand for a mindless “not C#” philosophy, which would be incredibly short sighted and is not what we’re doing. Just as C# borrowed a ton of concepts that VB made popular, we feel free to borrow their best ideas right back. Why not, if it helps our customers?

So, in the end, I think the whole “C# vs VB” argument is a non-starter. The real question is: are we doing a good job making your life easier? Are we the best tool for developers out there? That’s the important thing and what we focus on every day.

I’ve been converting some C# code into VB (because I think better in VB than I do in C#), and the conversion reminded me of another small feature of VB that people tend to forget about. Everyone who’s used Access or VB probably is familiar with the ! operator. Most of the time, you probably used it with DAO/ADO, something like: (Forgive me if the methods are wrong, it’s been a while since I wrote any non-ADO.NET code.)

rs.AddNew()
rs!CustomerName = "John Smith"
rs!Address = "10 Main Street; Seattle, WA"
rs!Phone = "(206) 555-1212"
rs.Update()

You probably used the ! operator because you saw someone else using it, and it was a lot easier than writing rs.Fields("CustomerName") = "John Smith". But you probably never thought about what, exactly, the ! operator was doing. Sadly, the operator has fallen somewhat into disuse because of the advent of strongly-typed datasets in ADO.NET. But it’s still quite handy!

The technical name for the ! operator is the “dictionary lookup operator.” A dictionary is any collection type that is indexed by a key rather than a number, just like the way that the entries in an English dictionary are indexed by the word you want the definition of. The most common example of a dictionary type is the System.Collections.Hashtable, which allows you to add (key, value) pairs into the hashtable and then retrieve values using the keys. For example, the following code adds three entries to a hashtable, and looks one of them up using the key “Pork”.

Dim Table As Hashtable = New Hashtable
Table("Orange") = "A fruit"
Table("Broccoli") = "A vegetable"
Table("Pork") = "A meat"
Console.WriteLine(Table("Pork"))

The ! operator can be used to look up values from any dictionary type that indexes its values using strings. The identifier after the ! is used as the key in the lookup operation. So the above code could instead have been written:

Dim Table As Hashtable = New Hashtable
Table!Orange = "A fruit"
Table!Broccoli = "A vegetable"
Table!Pork = "A meat"
Console.WriteLine(Table!Pork)

The second example is completely equivalent to the first, but just looks a lot nicer, at least to my eyes. I find that there are a lot of places where ! can be used, especially when it comes to XML and the web, where there are just tons of collections that are indexed by string. One unfortunate limitation is that the thing following the ! still has to be a valid identifier, so if the string you want to use as a key has some invalid identifier character in it, you can’t use the ! operator. (You can’t, for example, say Table!AB$CD = 5 because $ isn’t legal in identifiers.) In VB6 and before, you could use brackets to escape invalid identifiers (i.e. Table![AB$CD]), but when we started using brackets to escape keywords, we lost the ability to do that. In most cases, however, this isn’t too much of a limitation.

To get really technical, x!y works if x has a default property that takes a String or Object as a parameter. In that case, x!y is changed into x.DefaultProperty("y"). An interesting side note is that there is a special rule in the lexical grammar of the language to make this all work. The ! character is also used as a type character in the language, and type characters are eaten before operators. So without a special rule, x!y would be scanned as x! y instead of x ! y. Fortunately, since there is no place in the language where two identifiers in a row are valid, we just introduced the rule that if the next character after the ! is the start of an identifier, we consider the ! to be an operator and not a type character.