There has been a lot of customer interest in when the SyntaxEditor .NET Languages Add-on for WPF will be ready. About a month ago we posted the general design stages that are needed to create the add-on.
Today I’d like to review some of the new features being added to our LL(*) Parser Framework and Language Designer in version 2011.1, and will also show some screens of the C# grammar in action.
New Type-Specific AST Node Features
We’ve been plugging along on the C# grammar implementation. Part of this work involved sidetracking to add more enhancements to the SyntaxEditor LL(*) Parser Framework. A key new feature of these enhancements involves support for type-specific AST nodes.
The 2010.2 version supports AST nodes that implement IAstNode and our default tree constructors produce a default node type that has a string Value and can contain any other node as child nodes. What we’ve done in the recent enhancements for 2011.1 is augment our AST construction syntax to support type-specific AST nodes as an alternative to the default AST node type.
Type-specific nodes means that you actually have a class called CompilationUnit to represent your compilation unit, a class called ClassDeclaration to represent class declarations, etc. Each type-specific node can have various get/set properties and collection properties. So a ClassDeclaration class has a Modifiers property, a Name property, a Members property, etc.
Our enhancements to the LL(*) Parser Framework fully support creation of these type-specific AST nodes using similar syntax to how you currently perform tree construction. It’s actually quite interesting how it all works and we’ll hopefully post some examples on the blog soon. The best part is that you’ll be able to use all these features for your own custom language grammars too.
Language Designer Updates
Another related portion of updates is that our Language Designer app in version 2011.1 supports code generation of type-specific AST nodes. You simply configure a few details about the type, its properties, and we do the rest for you. We’ve constructed all our AST nodes for the C# language using this new feature.
First Screens of the C# Grammar
As mentioned above, we’ve been working on the C# grammar while making the above enhancements at the same time. Today we hit a first milestone of having the entire C# 4.0 specification implemented in our C# grammar. This means it’s able to fully parse C# files into its type-specific AST model.
Here’s some statistics on what we’ve done so far:
- Over 100 dedicated AST node classes created for use with the C#/VB grammars
- Well over 100 terminals in the grammar
- Well over 100 non-terminals in the grammar
Parsing a Compilation Unit
Let’s see a screenshot showing some C# code and a related AST:
Here we’ve created a small C# snippet with some invalid code. You can see the text representation of the AST that was generated on the right showing that it did fully-parse. You’ll also see a syntax error squiggle line. By hovering over it we can see that the parser reported an identifier was expected at that location.
Parsing a LINQ Query Expression
One interesting feature with the new grammar design is that we allow you to choose your root non-terminal from options like compilation unit, expression, or query expression. This feature has been requested by some of our customers.
In this screenshot we have set up our grammar to parse a query expression. You can see the resulting AST’s text representation on the right.
Next Steps
Now that our AST model has been created and the C# grammar productions are working pretty well, the next steps will be to start setting up unit tests and implementing proper error handling in the grammar. Error handling is important because most of the time, code in the editor will be in an invalid form. So the parser needs to know how to properly recover from error scenarios and continue on if it can.
We’ll continue to post more about progress as we hit more milestones.