Testing Testing

I know we all create test data with the “Test, please ignore” but I still found it funny when it appeared as a link in my local paper’s online edition:

SMH Testing

I’m sure that wasn’t supposed to make it to production. The horse story on the other hand …

IE7 Upgrade Fun

A while ago I installed the IE7 beta on my laptop. Today I thought I’d upgrade to the real thing. This made me laugh:


I never really bought that line about IE being part of the operating system but it seems that now even Microsoft can’t get rid of it once you install it 🙂

VB.Net Keywords

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.

C# 2.0 parsing

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();

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.

Clover.NET 1.2 Released

One of the reasons I had time to update my Blog software is that we, Cenqua, have recently released Clover.NET 1.2. There’s lots of good stuff in it but I won’t go into most of it here. Have a look at the announcement in our forums for more info. What I thought might be interesting to talk about are the issues in parsing VB.Net.

When we started to add VB.Net support to Clover.NET, I thought parsing VB.Net would be relatively easy. After all, on first inspection, for most statements, there is a corresponding “End” statement. I thought that the regularity that implied would make everything quite simple. If only it were so …

We started from the Microsoft VB.Net language specification and it’s a good start. Defining a grammar for a language parsr, however, is a precise art and it soon turns out that the real specification of VB.Net is the set of programs which can be compiled by vbc and not that specified by Microsoft’s grammar. Since releasing VB support, we’ve had a few reports of programs that out parser rejects. In most cases, we’ve found the program does not meet the language spec but it is accepted by vbc.

One example would be the specification of EventMemberSpecifiers. In the specifcation, the event specifier takes an Identifier. In reality, this can be either a keyword or an identifier. So, even though “select” is a keyword, the following is ok

Private Sub MenuItem1_Select(ByVal sender As Object, ByVal e As System.EventArgs) Handles MenuItem1.Select

End Sub
Since the MS grammar is explicit in other areas about allowing keywords or identifiers, it makes you wonder why it does not allow that here.

The ability to use keywords as identifiers is pretty unusual in a language. I wonder if that is a result of .NET’s multiple language ideas. It certainly makes parsing a challenge.

Another example is the block construction. A block is defined as a collection of one or more labeled lines, each of which must end in a LineTerminator, which is a CR or LF one one of the Unicode variants. So, when a TryStatement is specified to take a block, this should not be legal but is:

Try : stream.Close() : Catch : stream.Close() : End Try

So, a block can be terminated by a colon too, which is unfortunate as the colon is used for a few other things too.

Anyway, you get the picture. If you are parsing VB.Net, and using the specification as your guide, you’re in for a few surprises. It’s what makes life interesting, isn’t it?