CodeFeed

The VB.Net grammar has always had, at least for me, a strange approach to keywords. In contrast to many languages, VB allows you to, at least at the syntactic level, use keywords for identifiers in many situations. I guess it may have been to allow maximum operability with libraries implemented in other .NET languages.

The latest spec removes a lot of keywords while retaining their use within the grammar. C# also uses this technique of “context sensitive keywords”. Overall it’s a bit of a pain as you generally need to play games between the lexer and parser stages to make it work. Today I’m going to look at the preserve keyword which is, alas, not preserved.

A long time ago, in University, I used a book “Principles of Programming Languages” by Bruce MacLennan. It’s way out of date by now but I remember still how it put forth a set of priciples for langauge design including classis such as the zero-one-infinity principle. Anyway, one of the principles was “The regularity Principle: regular rules, without exceptions, are easier to learn, use, describe and implement”

The dropping of preserve as a keyword allows us to create a program which, I think, violates this principle:

Imports System

Module Test
Public Sub Main()
Dim preserve(2, 2) as integer
redim preserve(2, 4)
End Sub
End Module

This will not compile with my current version of vbc 2.0. If I change the name of the variable, however, it will. Isn’t that odd? I’m not sure of the motivation for removing the keywords when it really does seem to want to be a keyword.

I have recently been working on the parsing of C# and VB.Net as part of our development of Clover.NET for Visual Studio 2005 and .NET 2.0. I think it is fair to say that the changes to the language specs for both languages have increased the complexity of parsing both languages quite significanly. Over the next few days I’ll post some example code snippets that show off some of the problems we have encountered in testing our parsers for the new language features. If I get time I also want to discuss some of the general techniques we have used to simplify parsing.

To start with, today I’ll give a little example program which will compile with csc 1.1 but which fails to compile with csc 2.0 (I’m using the July CTP at this time). This example is inspired by the examples in the C# specification of March 2005 and centres around the ambiguity of the >> symbol in the presence of generics (I have to work hard not to type “templates” there). If I read the spec correctly, this should compile ok but, so far, Microsoft disagree and class this compatibility breakage as “by design”.

using System;

class X
{
static void Main ()
{
X x = new X();
x.runTest();
}

public int F(bool a, int b) {
return 2;
}

public void runTest() {
int a = 5;
int b = 6;
int c = 7;

int blah = F(a<b ,c>>2);
Console.WriteLine("Blah = " + blah);
}
}

The csc 2.0 compiler interprets the arguments in the call to F to be a generic, rather than two separate arguments. I guess it’s not a big deal in practice as the example is somewhat contrived. Nevertheless, I find the compatibility break disturbing.