Visual Basic

Reserved words: what are they good for? (Absolutely nothing?)

Paul Vick — Thu, 08 May 2008 12:01:00 GMT

Random musing for the day: I was thinking about reserved words in programming languages and whether they're really necessary at a lexical level. As you know, most programming languages define in their lexical grammar a set of words that cannot be used anywhere in the language except when explicitly specified in the grammar. For example, VB reserves the word "Object". So you can't just say:

    ' Error: Keyword is not valid as an identifier.
    Sub Object()
    End Sub

Many languages (such as VB) allow you to work around this by providing some sort of lexical escape that suppresses the reserved nature of the word. So you can say in VB:

    Sub [Object]()
    End Sub

Confusingly, many keywords that we've been adding to VB lately haven't been reserved words, to reduce the need to modify people's code when they upgrade. Instead, they've been contextual keywords, that is to say they're only reserved in certain syntatic contexts. For example, From is not a reserved word in VB in the lexical grammar, but if you start an expression with From and then follow it with an identifier, we say "Oh, yes, you're starting a query..." For example:

    Dim From As Integer = 10
    ' OK: Unambiguously the local variable
    Dim x = From + 10
    ' OK: Unambiguously a query
    Dim y = From a In New Integer() {1, 2, 3, 4}

Which leads me to wonder: why bother with lexically reserved words at all? Why not just make all of your keywords contextual? When I started on VB, I guess I just accepted the practice since that's what the language did before I showed up, but now I'm not so sure. Maybe there's some blindingly obvious reason that I'm not seeing (probably there is). I can think of some historical reasons why keywords weren't all contextual:

Maybe it simplified writing a parser in "the old days," or it simplified building a parser generator.
Maybe it was because people were writing code in editors that didn't have syntax coloring. "int int = 5; int = (int)int * (int)int / (int)int" looks pretty nonsensical if you don't have nice coloring to tell you which are the keywords and which aren't.
Maybe there were grammatical problems with doing it? The previous example makes me wonder about whether C could handle it; I'm not an expert on how the C grammar handles the cast operator.

Anyway, it's not extremely relevant at the moment--we're not going to just start unreserving all the keywords in VB--but just something interesting to think about...

Collection initializer expressions

Paul Vick — Mon, 05 May 2008 18:23:00 GMT

WARNING: This is a speculative post. Caveat emptor.

Well, I appear to be on a rhythm of about once a month posts, which seems OK for the moment. Moving on to another "future" topic, one of the most annoying things that we cut (at least, from my perspective) from VB 2008 was collection initializers. Collection initializers were a little different than the corresponding C# feature, because our plan was to introduce stand-alone initializers that didn't have any intrinsic type. Instead the initializers "snap to" a particular type when they're converted to it, just like lambdas and AddressOf expressions. For example:

' This works since VB 7.0!
Dim a() As Integer = {1, 2, 3, 4}
' This now creates a list.
Dim b() As List(Of Integer) = {1, 2, 3, 4}
' This assigns a new list to b.
b = {5, 6, 7, 8}

' If M takes Integer(), that's what it'll get. If it takes List(Of Integer), that's what it'll get.
M({1, 2, 3, 4, 5})

This is kind of nice, in that you can initialize collection types and arrays without having to state a type at all. We do the same trick C# does about looking for an Add method on a object that implements IEnumerable, so you can also use this syntax to initialize dictionaries:

Dim d As Dictionary(Of Integer, String) = {{1, "One"}, {2, "Two"}, {3, "Three"}}

All this is pretty straightforward, but there is some discussion about what type you should get if there is an absence of a target type. For example, assuming that local type inference is on, what should the following be typed as?

Dim x = {1, 2, 3, 4}

Our initial thought was that we should just infer the dominant type of the initializer and then create an array of that type. So the above example would type x as Integer(). And then the following:

Dim y = {{1, 2}, {3, 4}, {5, 6}}

Would infer a type of Integer(,), a two-dimensional array of Integer. With more nesting, you'd get more dimensional arrays. However, as we talked about it more, it seemed like maybe it might be more useful to infer List(Of T) for the 1-dimensional initalizer, Dictionary(Of K, V) for the 2-dimensional initializer, and nothing for more dimensions. So the type of x would instead be List(Of Integer) and the type of y would be Dictionary(Of Integer, Integer).

Both seem reasonable, so I'm curious what people would think. Remember, we will only fill in a type if we're in a context (like type inference) where there's no target type to use. We'll always use a target type if there is one.

Implicitly implemented interfaces

Paul Vick — Mon, 07 Apr 2008 15:59:00 GMT

WARNING: This is a speculative post. Caveat emptor.

This one is a little more speculative than the others, but it’s something that we’d like to get some feedback on. One complaint that we get from time to time has to do with interface implementation. A lot of people like the fact that there’s a nice explicit interface implementation syntax in VB, but sometimes it starts to feel, well, a little verbose. Even if you let the IDE create all the interface implementations for you, there’s still a lot of extra characters with all those “Implements IFoo.Bar”s, especially when the implementing method is the same name as the interface method.

One idea we’ve been kicking around is relaxing our rules to allow for implicit interface implementation. Today, when we’re checking interface implementation for some interface I1 what we do is:

Check to see if any base classes implement any of the members of I1. If so, we mark those methods as implemented.
Check to see if the current class implements any of the members of I1. If so, we mark those methods as implemented. If the current class implements a method that a base class implemented, the current class replaces that implementation.
If all of the methods of I1 are not implemented, we give an error.

What we would do is slightly modify the rules to:

Check to see if any base classes implement any of the members of I1. If so, we mark those methods as implemented.
Check to see if the current class implements any of the members of I1. If so, we mark those methods as implemented. If the current class implements a method that a base class implemented, the current class replaces that implementation.
If there are any methods of I1 that are not implemented, we check to see if there is a method with the same name and signature in the current class, and if there is, then that method implements the interface method.
If all of the methods of I1 are not implemented, we give an error.

What this would mean is that you could do something like this:

Class C1
    Implements IComparable(Of Integer)

    Public Function CompareTo(ByVal other As Integer) As Integer

    End Function
End Class

And not get any errors. There are a couple of things to note here if you’re familiar with C#, though. First, unlike in C#, if you declare a method in a derived class that has the same name as an interface method that is declared in a base class, you will still have to explicitly implement the interface method if you want the derived class method to take over. For example:

Class Derived
    Inherits Base
    Implements IComparable(Of Integer)

    ' Will not take over IComparable(Of Integer).CompareTo since Base already implements it!
    Public Function CompareTo(ByVal other As Integer) As Integer

    End Function
End Class

One could argue whether the derived class should or shouldn’t take over the implementation, but the bottom line is that if we allowed this we would be opening a potentially serious backwards compatibility problem. The above code could be written today (assuming Base implements IComparable(Of Integer)), and CompareTo will not take over the implementation of the interface. If recompiling your application in some future version of VB switched the implementation, this could introduce a very subtle and possibly very bad bug into your program. So it’s really a non-starter.

The other difference from C# is that we won’t search base classes for implicit interface implementations. For example, the following code would still give you an error:

Class Base
    Public Function CompareTo(ByVal other As Integer) As Integer

    End Function
End Class

Class Derived
    Inherits Base
    ' Error: IComparable(Of Integer).CompareTo is not implemented!
    Implements IComparable(Of Integer)
End Class

This can also be debated, but in the end we tend to err on the side of being more conservative—since Base didn’t implement IComparable(Of Integer) itself, it seems odd to pick it up when implementing the interface, as we have no way of knowing for sure that it’s really appropriate. There are also other highly technical issues relating to the mechanics of interface implementation that would make this situation complicated, especially if Base was in another assembly that we had no control over.

So the question is: would people find this useful? Annoying?

Automatically implemented properties

Paul Vick — Thu, 27 Mar 2008 15:30:00 GMT

WARNING: This is a speculative post. Caveat emptor.

I apologize for the long silence, things have been a little busy around Panopticon Central these days! Anyway, I wanted to go back to talking about some of the things that we’re thinking about for the next version, and I thought I’d go over a small one: automatically implemented properties. As the name implies, these would be basically the same thing you get in C# 3.0’s auto-implemented properties.

What we’re talking about is allowing you to have a simple property declaration like so:

Public Property x() As Integer

This would generally expand under the covers to look something like this:

Private _x As Integer
Public Property x() As Integer
    Get
        Return _x
    End Get
    Set(ByVal value As Integer)
        _x = value
    End Set
End Property

The one major difference that we’re considering from C#’s auto-implemented properties is to allow initializers on the auto-implemented property. In other words, something like:

Public Property x As Integer = 10
Public Property y As New List(Of Integer)()

I think C# also doesn’t let you bind to the underlying field, but just like with other auto-generated stuff in VB, I think we’d err on the side of allowing you to bind to it if you really needed to. You can also make them Overridable if you like, to allow derived classes to provide their own implementation.

Just a little feature, but one that can be useful.

Implicit line continuations

Paul Vick — Wed, 27 Feb 2008 16:55:00 GMT

WARNING: This is a speculative post. Caveat emptor.

One of the things that we'd like to address in the next version is line continuations. We know that they tend to annoy many developers who want to break their logical lines across multiple physical lines, and we've gotten many requests to get rid of them altogether. Unfortunately, there's a reason we haven't just dropped them--they actually are needed in certain scenarios. For example, take the following contrived example:

    Sub Main()
    End _
    Sub

If I remove the line continuation, I'll now get a compile error because "End" now is the "End" statement, and the Sub looks like it's trying to start a new subroutine in the middle of the current subroutine. There are quite a few of these syntactic ambiguities sprinkled throughout our grammar, some of which might be quite obscure and unnoticed until someone's code actually broke. So instead of taking a maximalist approach and trying to remove the line continuation everywhere, we've been thinking about a more minimalist approach and looking at where removing the line continuation might be most useful. This produced a much more tractable list of places where we might productively remove the line continuation. In particular:

After binary operators in expression contexts. Note that this does not include assignment operators. For example:
```
a = b +
    c
```
After the following punctuators: comma (","), open parenthesis ("("), open curly brace ("{"), begin embedded expression in XML ("<%="). For example:
```
Console.WriteLine(
    "{0} {1}",
    FirstName,
    LastName)
```
Before the following punctuators: close parenthesis (")"), close curly brace ("}"), end embedded expression in XML ("%>"). For example:
```
Console.WriteLine(
    "{0} {1}",
    FirstName,
    LastName
)
```
After an open angle bracket ("<") in an attribute context, before a close angle bracket (">") in an attribute context, and after a close angle bracket in a non-file-level attribute context (i.e. an attribute that does not specify "Assembly" or "Module"). For example:
```
    <
        Conditional("Foo"),
        Conditional("Bar")
    >
    <
        Conditional("Baz")
    >
    Sub Main()
    End Sub
```

Before and after query expression operators. For example:

Dim ys = From x In xs
         Where x > 5
         Select
            ten = x * 10,
            twenty = x * 20,
            thirty = x * 30

One thing that is not currently on the list is allowing an implicit line continuation after a dot, so you couldn't break up "a.b.c" implicitly. It's not that we can't do dot, just that it's quite a bit more expensive and problematic for Intellisense. We'd be interested to hear if this is something people really want to/need to do, or if it's just a nice-to-have.

Are there any other places that we missed that you can think of?

Lang .NET 2008, Scripting, and Visual Basic

Paul Vick — Wed, 20 Feb 2008 17:02:00 GMT

WARNING: This is a speculative post. Caveat emptor.

Several weeks ago, I gave a presentation entitled Bringing Scripting (Back) to Visual Basic at the Lang .NET 2008 conference. A video of the presentation has now been posted, so you can check it out for yourself. (The presentation was also covered by EWeek in an article entitled Bringing Sexy Back to Visual Basic.)

The main theme of the presentation is the same one I've been talking about on and off over the past year or two: moving Visual Basic back towards it's scripting roots. The main thrust of this presentation was the technical side of the story--namely, what we would need to do to the existing Visual Basic compiler to be able to effectively use it as a scripting engine. The presentation talks some about the way the compiler is structured, how it might change and some of the things were thinking about enabling. In particular, what we'd like to see is not just that Visual Basic can be embedded anywhere, but that all the services that the compiler provides--parsing, semantic analysis, code generation--are available to be used by any program that needs them. The DLR is a key part of this, but there's a lot of work on top of that.

I also showed some fun demos of some prototypes that we've whipped up using our current codebase. Nothing we're committing to at the moment, but it gives you some of the flavor of what we're thinking about.

One thing this presentation didn't cover (and which Ted Neward brought up in the Q&A afterward) is what we might do to the language itself to make it more scripting-friendly. That's an area where things are less well-defined and even more speculative than what I talked about, so I left it out for now. Maybe soon I can talk more about it...

Visual Basic Yesterday, Today and Tomorrow

Paul Vick — Thu, 27 Dec 2007 16:07:00 GMT

A month or two ago, Paul Yuknewicz and I sat down to record a Hansselminutes podcast with Scott Hanselman, talking about the past, present and future of Visual Basic. It was a lot of fun, check it out!

Also, here's a little holiday love for VB from some Microsofties you might recognize:

(Almost) final VB 9.0 language specification posted

Paul Vick — Thu, 27 Dec 2007 16:02:00 GMT

I wanted to let people know that an (almost) final VB 9.0 language specification has been posted on the download center. The spec is missing some copy-edits from the documentation folks, but is otherwise complete. Since I'm not going to get a chance to incorporate the copy-edits until I am back from vacation in January, I wanted to get the spec out there for anyone interested in documentation of the XML features that weren't present in the previous version of the spec. (I apologize for the lateness of this vis-a-vis the release of the product itself, it's been a busy fall.)

This updated language specification corresponds to Visual Studio 2008 and covers the following major new features:

Friend assemblies (InternalsVisibleTo)
Relaxed delegates
Local type inferencing
Anonymous types
Extension methods
Nullable types
Ternary operator
Query expressions
Object initializers
Expression trees
Lambda expressions
Generic type inferencing
Partial methods
XML Members
XML Literals
XML Namespaces

Questions, comments or criticisms can be sent to basic@microsoft.com. Thanks!

Did something important happen today?

Paul Vick — Tue, 20 Nov 2007 00:29:00 GMT

Oh, yeah, that's right. We shipped. Hard to believe we've finally reached the finish line...

Is it time to replace Mort?

Paul Vick — Wed, 14 Nov 2007 17:30:00 GMT

Most everyone who's steeped deeply enough in the culture of Visual Studio has probably run across some mention of Mort. Mort is one of a triumvirate of personas that the Visual Studio team uses to describe the developers that they are targeting. The other two members of this group are Elvis and Einstein. (I got complaints from internal people the last time I mentioned the personas, so let me take a moment to say that they are open knowledge.) Love them or hate them, the personas have become an integral part of the way that many people talk about VB, C#, and C++, both inside and outside the halls of Microsoft.

There is a problem, though. Let me illustrate, if I may. First, here's Einstein:

A bit of a card, to be sure, but generally a pretty brilliant guy. Sure, he's spent most of his life chasing some crazy theory of unification, but overall he's the go-to guy when you've got some rocket science project. And, of course, he's the one claimed by the C++ folks. (Since you pretty much have to be a rocket scientist to fully grok C++...)

Next, we've got Elvis:

OK, so maybe Elvis's best years are a little bit behind him and he's just been coasting on his youthful talent. And, yes, maybe he's been hitting the corn dogs a little bit too hard. But, c'mon... He's Elvis, for heaven's sake! The King! Maybe you don't call him if you want to go to the Moon in a rocket, but if you want to entertain a stadium's worth of rabid, screaming fans who won't notice he's, um, a little overweight, he's your man. And, of course, he's claimed by the C# folks.

Now, we finally come to Mort:

Hmmmm. Well. Yes.

Now, I should say that this is not the way that I think of Mort. Or that this is the way that our team thinks of Mort. To me, Mort is a smart, pragmatic guy who's more interested in rolling up his sleeves and saving the world than sitting around noodling on some unified field theory or eating copious amounts of doughnuts. But to a large slice of the world who have an opinion about Mort, this is who they see. A toothless, unkempt hillbilly who's best kept up in the mountains of West Virginia and away from all nice and normal folks.

And, of course, he's the one claimed by the VB folks. He's us. See the problem?

Personally, I think it's time to let go of the Mort persona. Send him a nice fat check, a referral to a good orthodontist, and thank him for his hard work. And in his place? Well, I'd like to propose hiring this guy as our new persona:

Ben, as I'll call him, is a pretty pragmatic guy and a bit of a polymath, a jack-of-all-trades. In between a writing and political career, he also finds time to be a postmaster, a publisher, a scientist, and an inventor. In short, he does what most VB programmers do: he multi-tasks like crazy, solving problems wherever he goes. (More information about Ben can be found here, for those not steeped in American history.) Now, sure, Ben's not some rock star like your average George or Thomas is, getting all the attention with flashy military or political antics, but he's really your guy when you need something done, you need it done right, and you need it done with a minimum of fuss and bother.

Doesn't Ben sound like a wonderful persona for VB?

Of course, when it comes to product planning stuff like this, what I think doesn't really matter a hill of beans. I'm sure there's no getting rid of Mort, no matter what some people may think of him. But we can dream, can't we?