Category Archives: Visual Basic 2010

Implicit line continuations

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:

  1. After binary operators in expression contexts. Note that this does not include assignment operators. For example:
    a = b +
        c
  2. After the following punctuators: comma (“,”), open parenthesis (“(“), open curly brace (“{“), begin embedded expression in XML (“<%=”). For example:
    Console.WriteLine(
        "{0} {1}",
        FirstName,
        LastName)
    
  3. Before the following punctuators: close parenthesis (“)”), close curly brace (“}”), end embedded expression in XML (“%>”). For example:
    Console.WriteLine(
        "{0} {1}",
        FirstName,
        LastName
    )
  4. 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
    
  5. 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

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…

The big "D"-word

WARNING: This is a speculative post. Caveat emptor.

I know that I’m running a great risk of touching the third rail of the VB community by even speculating about this, but it seems like the right time to have a bit of a conversation about the big “D”-word.

That is, deprecation.

Yes, deprecation. Now before anyone starts freaking out, foaming at the mouth or writing a petition, let me emphasize that my thinking along these lines is entirely within the guidelines discussed in the language specification, which mandates a long and gradual process of deprecation that involves continuing to support the deprecated feature for a reasonable period of time. The guidelines also state in part:

…feedback must be solicited from the user community on deprecation of the feature and full notice given before any final deprecation decision is made. The deprecation process may be reversed or abandoned at any point based on user community feedback.

So I’m really just floating some personal trial balloons here. After all, it’s now been almost three major releases since the big move to .NET, and I think it’s started to become clear that some of the features we carried forward are a bit, uh, underused. In the interest of paring down the language specification just a bit in it’s inevitable march towards more and more pages, I’ve been pondering the question: “If I was going to deprecate parts of the language that don’t seem to be used, what would I deprecate?” I’ve come up with a few candidates that seem pretty safe:

  • Type characters. Yes, we still allow you to say “Dim a$”. So far as I have ever seen, no one uses them anymore. It would be nice to reclaim a bunch of characters at some point in the future, and it would be relatively easy to include error corrections to fix this up.
  • Copying of boxed value types. I’m not even sure I could explain this in a bullet point. If you read section 8.6 of the language spec, Value Type Conversions, it’ll discuss this a little more detail. I think this is counterintuitive behavior for most people and is incomplete in any case. The only real question here is: are there programs that depend on this behavior? We’d need to think/talk a lot more about it before we could even consider this one.
  • Mid$() assignment. Bet you didn’t know you could even do this, did you? See section 10.6.3 in the language spec for more on this.
  • End statement. I’m curious if this one is still used by people, especially now that most frameworks like WinForms and WPF have Application objects that have a proper Exit/End method. If this one is popular, it might not fly as deprecatable.
  • Erase statement. I’ve found that ReDim is actually still fairly useful as a shorthand way to redimension an array. However, Erase is completely useless–you could just replace it with an assignment to Nothing and you’d get the same thing.
  • REM comments. Bet you didn’t know you could even do this one either, did you? There’s something nostalgic about it (Erik Meijer loves them), but, really, who uses them anymore?

You’ll note that I’m only including things here that I think are truly not used much or not useful. There are things I think some people would like to see disappear (like, say, On Error), but are still being used heavily enough to make them be not reasonable candidates.

I’m curious what’s people’s feelings about this are. Does this just bring up bad memories? Are there other candidates you’d throw on the list? As I said, at this point, I’m just talking. Depending on the reaction, the next step would be to look a little more formally at it in the team…

What’s on my mind for VB10 (and yours?)

WARNING: This is a speculative post. Caveat emptor.

Last week, one of the VB MVPs asked on a private alias what our thinking was about VB10. As I kind of indicated in my previous entry, I don’t think we have a clear idea yet of what’s going to be on the table for the next rev-VB 2008 was kind of an aberration in that LINQ was in gestation long before VB 2005 even shipped. But I can say what’s at least on my mind:

  • Hosting or, more generally, opening up the compiler services to the outside world.
  • Decreasing lexical “noise” when looking at VB code.
  • Increasing the extensibility of the language so that it takes less work to extend the language and can be done by libraries (Ruby is an example of what I’m thinking of here, but only a general example).
  • Addressing UNDONE tasks from Orcas (object initializers, statement lambdas).
  • Addressing persistent annoyances (line continuations is a good example here).
  • Addressing whatever else comes up from the community as we release VB 2008.

I know that I’ve already added the usual caveats above, but I want to make double clear this is just what’s on my mind at the moment-in other words, things that I’m personally thinking about. These are not official team priorities, planned for the next rev, or anything like that. The next version could look radically different than the list above. I should also add that I mostly think about the language, so that’s why this list doesn’t talk about the IDE.

I’d be interested (in keeping with the last bullet point) what people might be specifically in for the next release. What’s at the top of your list these days?

An update on VBx…

Things have been pretty quiet around Panopticon Central since I did a bit of talking about “VBx” back in May. Partially this has reflected the fact that we’re at a pretty early stage of thinking about the post-VS 2008 world, so there isn’t a lot solid to talk about. Partially this has reflected the usual shifts in emphasis and strategy that occur around the end of a major product cycle as more and more people start to get freed up to think beyond what they’re delivering next month. And partially this has reflected that I’ve got two kids at home now, and that just seems to suck up some of the extra time that I used to use for blogging…

That said, I think it’s worth spending a moment catching up on what’s going on with “VBx” (at least that I can talk about in public).

I think the first thing that’s worth saying is that pretty much everyone seemed to dislike the codename “VBx,” mostly because it overlaps too much with the old VBX controls and partially because it seemed to imply that we were developing another version of the language (which we aren’t). Fair enough. For the moment, then, instead of talking about “VBx,” I’m going to talk about “VB10”. This isn’t an official codename at all, just a personal shorthand way of referring to “the next major version of Visual Basic.” Maybe it will be version 10, or maybe it won’t, but I hope it will be a little less confusing than “VBx” was, in that it should emphasize the continued unity of the VB language.

Back in May, our goal was to have something to CTP in the PDC07 timeframe, which would have been this month. But that turned out to be a more aggressive timeframe than expected. However, even if we haven’t got something solid to CTP just yet, we’ve still got some ideas of where we’re headed and what you might expect to see in VB10. So over the next few months, my goal is to write some speculative pieces on what we are thinking. The purpose would not be to make feature commitments or say what’s definitely in or out of the next version, but instead to get some of our ideas out there and see what people think, see whether there is any traction or not, and determine if we’re crazy or not.

Each entry, though, would need to come with some pretty heavy caveats. To wit:

WARNING! This is a speculative post. It reflects the individual thoughts of the author at a particular point in time. It does not necessarily reflect the future beliefs of the author, nor does it necessarily reflect the beliefs, current or future, of the team as a whole. No conclusions can or should be drawn from this article about future features, plans, or directions of the Visual Basic language. These features may show up in the product as some point, or they may not. If they do show up, they may not look or work as described here. Caveat emptor. No warranties expressed or implied. Your mileage may vary. Fnord.

I hope this will give people a pretty accurate idea of how big a grain of salt to take them with…

What does the PDC cancellation mean for VBx?

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…

After MIX, how many Visual Basic languages are there?

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…

What the heck is "VBx"?

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!

Discussing VB, scripting, dynamism and such

As the eagle-eyed may have noticed, I recently added a new post category called “VB/Script.” In it I have collected a number of posts that I’ve written over the years concerning VB, scripting, dynamism and so on. Specifically, I’ve pulled together (in chronological order from earliest to latest):

I’m doing this because I expect that in the coming months/years I’ll be talking more about these kinds of things, and I want to make sure they’re all easily accessible. A couple of quick notes on the category name, though. First, I put that slash in there to emphasize that I am not talking about VBScript, the IActiveScript script engine, per se. I’m just talking about “VB” and “scripting.” And, second, I realize that the term “scripting” is so incredibly overloaded as to be practically meaningless—for example, “scripting” doesn’t necessarily mean “dynamism,” even though I’m lumping them together here. However, I don’t want a category named “VB/Scripting/Dynamism/Etc,” so I’m just going to pick a single term and figure that everyone can figure out what I mean. Hopefully, you all can… <g>